Does not having a secret defined for an IdentityServer4 API Resource introduce a security vulnerability?
I'm a little confused on the Introspection Endpoint, when it is used, and whether or not someone could use the Introspection endpoint to bypass Authorization and access an API without a defined secret (by a POST with just the API name as a parameter).
Is this possible? Or is the introspection endpoint only authorized through defined clients that use something like the Client Credential Grant?
The introspection endpoint will only validate a posted token, it shouldn't accept an API name in its request.
It can be used to validate reference tokens (or JWTs if the consumer does not have support for appropriate JWT or cryptographic libraries). The introspection endpoint requires authentication using a scope secret.
http://docs.identityserver.io/en/release/endpoints/introspection.html
This shouldn't be an endpoint you need to implement, it is included by identity server in the same way as the '.well-known/openid-configuration'.
A use case for this endpoint would be an API being passed a token and wanting to confirm its genuine and still valid (not expired or revoked), the response would include the claims associated with the token (users claims with the tokens scope taken into consideration)
For introspection security considerations see the RFC 7662 Section 4
An API Resource requires a Client Secret when you are using the Authorization Code Flow as its sending claims on the back channel.
If you are using Reference tokens you will also require a Client Secret, as the access token is never presented to the client, but instead the reference token is passed from the client to the api resource, and then onto the identity server in exchange for the access token.
It really depends on the client and the flow.
Related
My MVC client's access token contains an "idp" claim that my simple server-to-server client's token doesn't. I don't explicitly request idp on either clients, so where is this claim coming from? I thought it was part of "openid", and since it is available by default to MVC client, you don't need to request it, but I couldn't find any documentation/specification that confirms it. By the way, I am unable to add the openid scope to my serer-to-server client, as I am getting "invalid scope" error when I do that. What I am trying to do here is to get the "idp" claim into the token for my server-to-server client as well, but not sure if that's possible. Can someone point me to the right direction?
When you do server to server communication using the client-credentials flow, there is no user involved and hence the openid scope has no purpose. As its core purpose is to ask for the subject claim (the user Id).
The idp claim is not part of any scope and is usually added by IdentityServer.
Why do you neeed the idp claim? Your API and client both trusts the shared IdentiyServer.
idp claim in Identityserver stands for external identity provider (such as Google). That's why it does not have any sense when you request a token from your local IdP with "service_credentials" flow. If you are interested in the info about the token's issuer, just use iss claim instead. If you are sure you need the idp (or any other custom) claim in each and every token, you can involve a custom ClaimsService as I explained in my previous answer.
I would like some clarification on how to use ID tokens and access tokens in an implicit grant flow.
I have an Angular SPA using MSAL.js for Angular package and a Web API. The API does NOT call any external services, like MSFT Graph. The back end uses role claims from JWT to establish RBAC authorization to our API functionality only.
This doc says:
https://learn.microsoft.com/en-us/azure/active-directory/develop/id-tokens
id_tokens are sent to the client application as part of an OpenID Connect flow. They can be sent along side or instead of an access token, and are used by the client to authenticate the user.
ID Tokens should be used to validate that a user is who they claim to be and get additional useful information about them - it shouldn't be used for authorization in place of an access token.
This doc shows an authentication flow where a web API is called with an ID token instead of an access token:
https://learn.microsoft.com/en-us/azure/active-directory/develop/v2-oauth2-implicit-grant-flow
This sample code sends ID token too (calling own Web API sample):
https://github.com/Azure-Samples/active-directory-javascript-singlepageapp-dotnet-webapi-v2
The sample back end validates ID token audience against Client ID of the app that issued it.
Given our API is the only consumer of tokens, should we use ID tokens or access tokens?
Generally speaking, when securing your API with the Microsoft Identity platform, clients should be using the access token when making API requests, not the ID token.
check this part
It first calls acquireTokenSlient, which gets a token from the cache if available if not
it calls acquireTokenPopUp which will get an acces token for the specific scope, I am not sure if it would open up a popup window or will get a token in the background with hidden iframe. But it would fetch an access token for sure. API can never be accessed with ID token.
check https://learn.microsoft.com/bs-latn-ba/azure/active-directory/develop/scenario-spa-acquire-token for more clarification
I'm working on a SPA application, and I'm using the recommended implicit flow and I'm able to get access_token and id_token. As I need more than the profile info, I've created a separate endpoint to return the user profile information (along with all the other information that's specific to our business) and this endpoint is protected, and can be accessed only with an access_token as the bearer token. Right after getting access_token in SPA, I call this endpoint to get all the user information (which includes first name, last name etc., that gets displayed on the UI). If there is any problem with the returned id_token and access_token pair, the user profile info endpoint call would fail. So, do I really need to validate the id_token? as I'm not relying on any information within that token.
For authenticating against external login provider or authorization code flow, validating the id_token makes sense, but in my case I'm not sure about it.
According to OpenID spec:
When using the Implicit Flow, the contents of the ID Token MUST be validated in the same manner as for the Authorization Code Flow, as defined in Section 3.1.3.7, with the exception of the differences specified in this section.
1. The Client MUST validate the signature of the ID Token according to JWS [JWS] using the algorithm specified in the alg Header Parameter of the JOSE Header.
2. The value of the nonce Claim MUST be checked to verify that it is the same value as the one that was sent in the Authentication Request. The Client SHOULD check the nonce value for replay attacks. The precise method for detecting replay attacks is Client specific.
Why don't you utilise response_type parameter in authorisation request. By changing its value, you can alter what you receive for authorisation response.
Identity documentation mention about possible response type values. Following is an extraction from their documentation,
As you can see, if you do not want SPA to receive the id token, you can set the response_type value to token. If you do so you will only get an access token, which is enforced by OAuth 2.0 specification. (See the OAuth 2.0's implicit flow response_type explanation from here). Note that when you use response_type=token , you are using OAuth 2.0 (not OIDC)
I don't see any wrong in your approach as long as you utilise features enabled by respective protocols.
We have several API's that we'd like to grant access to a client via client credentials flow. The flow would go something like this.
Client gets a token from is4 based on some scope
Client hits first API with token
Client needs to hit second API with same token.
Authorization of the token at the API endpoint seems to only work when the APIResource matches the APIName in the authentication parameters.
How do you set up APIResource/Scopes such that this scenario can be accommodated?
OK I had the chance to play a bit with your case and have a solution.
So, as you know, the client credentials flow, works based on (except the clientid and client secret) ApiResoirces/Scopes.
Your API's, in their authentication configuration, have:
ApiName - for .NET Core API
RequiredScopes - for .NET Framework API
Depending on your case, you have to set them.
These are the APIResources/Scopes, that your IDS client should have, in its allowed scopes/api resources (Client.AllowedScopes).
Then, when requesting the client credentials, from the token client, you should pass as scope, a string, containing the both scopes/apiresources separated with interval (tokenClient.RequestClientCredentialsAsync("api1 api2");)
Then the access token, that you receive in the response, will be valid for calls for both of your api's.
You also have the second option, in which both your api's use one and the same scope/apiresource, but I don't think that this is a good approach at all.
In Azure AD, when we make a call such as AuthenticationContext.AcquireTokenAsync(resource, new ClientAssertionCertificate(_clientId, _cert)) it is not clear what exactly happens.
What part of the certificate gets exchanged if any?
Is there a challenge/response taking place?
Is the private key needed on the client as a part of this?
There are two ways you could go about finding the answer to you questions. One would be to look at the Microsoft Active Directory Authentication Library (ADAL) for .NET source code on GitHub, since this is open-source. The other (which we'll do here) is to looking at the network request that AcquireTokenAsync(String, ClientAssertion) generates, and work backwards from there.
Using Fiddler (or any other traffic analyzer), we can see something like the following (formatted for readability):
POST https://login.microsoftonline.com/{tenant-id}/oauth2/token HTTP/1.1
Content-Type: application/x-www-form-urlencoded
grant_type=client_credentials
&resource=https%3A%2F%2Fgraph.windows.net
&client_id={app-id}
&client_assertion_type=urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertion-type%3Ajwt-bearer
&client_assertion=eyJhbGciOiJSUzI1N...VE8wHSf-HZvGQ
Breaking it down:
grant_type=client_credentials tells us this is a token request using the OAuth 2.0 Client Credentials Grant flow.
resource=https%3A%2F%2Fgraph.windows.net gives the URI of the resource the client is requesting an access token for. In this case, it's for the Azure AD Graph API.
client_id={app-id} is the client identifier. In Azure AD, this is the app ID of the application that was registered.
The presence of client_assertion_type and client_assertion are indicative that the client is using an assertion to authenticate:
client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer says that client assertion being used is a signed JSON Web Token (JWT).
client_assertion=eyJhbGciOiJSUzI1N...VE8wHSf-HZvGQ is the aforementioned signed JWT token. The authorization server (e.g. Azure AD) will validate the contents, and check that the token was indeed signed by the certificate authorized for the client in question.
So, what ADAL does is:
Construct a token with a set of claims about the client (your app)
Use your certificate's private key to generate a cryptographic signature of those claims
Bundle that up into a signed JWT
Make an appropriately formed token request to the authority
During AcquireTokenAsync, only the certificate's thumbprint is provided (it's included in the JWT header to help the authorization server look up the corresponding public key). The JWT's signature is what proves that the client is in possession of the private key. However, before AcquireTokenAsync(String, ClientAssertion) can be used successfully, the client owner (i.e. you) needs to have provided Azure AD with the certificate's public key.
There is no challenge/response taking place here. The token is obtained in a single request, initiated by the client.
For a lot more detail, you can review the standards that this all implements:
RFC 6749: The OAuth 2.0 Authorization Framework
RFC 7521: Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants
RFC 7523: JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants
RFC 7519: JSON Web Token (JWT)
(Note that ADAL has a cache. Everything I described above will take place only if ADAL does not find a valid access token in the token cache. You can use AuthenticationContext.TokenCache.Clear() to clear the cache for experimentation.)