What is best practice when it comes to AWS API Gateway Authorization via tokens? Reading mixed messages from AWS in terms of which token to use for API Gateways.
Traditionally, the Access Token is meant of API Authorization via scopes and claims on the token.
However, AWS Cognito allows little flexibility with Access Token claims.
This example on AWS: https://aws.amazon.com/blogs/security/use-amazon-cognito-to-add-claims-to-an-identity-token-for-fine-grained-authorization/ Even goes as far to us the Id Token for their Authorization. Since you can add/remove claims from the Id Token using the Pregen lambda but you can't with the Access Token.
Am I better off trying to get the Access Token to work in a more creative way for specific users than claims? Can using the Id Token like an Access Token to my API's cause any issues in the future?
Using access tokens in APIs is the standard. ID tokens do not contain scopes and do not have the correct lifetime and renewal behavior.
One of the good things about Cognito access tokens is that they do not reveal sensitive token data to internet (web and mobile) clients. This makes them a little similar to reference format access tokens.
You do not have to do JWT authorization in the gateway. In fact an emerging zero trust security model is for each API to verify the JWT itself, to prevent potential threats inside the network.
One option to extend access token claims is to validate the JWT in the API, then look up custom claims (eg from your business data), then add them to a Claims Principal used by your API's logic.
This pattern is followed in this code of mine, which uses Cognito access tokens. This adds a little complexity, but results in portable API code.
For simpler use cases, using the ID token in APIs may be sufficient and more convenient, as long as you understand the limitations.
Related
I'm looking for guidance and/or best practices in implementing step-up authentication. The generic scenario is as follows: user logs in to web app using some identity provider, user then goes to some specific area of web site which needs to be protected by additional MFA, for example OTP. All functionality for the website is via REST API, authenticating with JWT bearer token.
The best description of the flow I found is from Auth0 here. Basically, user acquires the access token with scope which is just enough to access APIs that do not require additional protection. When there is a need to access secure API the authorization handler on backend would check if the token has the scope indicating that the user has completed the additional MFA check, otherwise it's just HTTP 401.
Some sources, including the one from Auth0, suggest using amr claim as an indication of passed MFA check. That means that identity provider must be able to return this claim in response to access token request with acr_values parameter.
Now, the detail that is bugging me: should the frontend know in advance the list of API that might require MFA and request the elevated permissions beforehand, or should frontend treat the HTTP 401 response from backend as a signal to request elevated permissions and try again?
Should identity provider generate relatively additional short-lived token to access restricted APIs? Then, if frontend has 2 tokens it must definitely know which token to use with which API endpoint. Or maybe identity provider can re-issue the access token with normal lifespan but elevated permissions? Sounds less secure then the first approach.
Finally, do I understand the whole process right or not? Is there some well documented and time-tested flow at all?
CLIENTS
Clients can be made aware of authentication strength via ID tokens. Note that a client should never read access tokens - ideally they should use an opaque / reference token format. Most commonly the acr claim from the ID token is used.
This can be a little ugly and a better option can sometimes be to ask the API, eg 'can I make a payment'? The client sends an access token and gets a JSON response tailored to what the UI needs. The API's job is to serve the client after all.
APIs
APIs receive JWT access tokens containing scopes and claims. Often this occurs after an API gateway swaps an opaque token for a JWT.
The usual technique is that some logic in the Authorization Server omits high privilege ones, eg a payment scope or claim, unless strong authentication was used.
It is worth mentioning plain old API error responses here. Requests with an insufficient scope typically return 403, though a useful JSON error code in an error object can be useful for giving the client a more precise reason.
STEP UP
As you indicate, this involves the client running a new code flow, with different scope / claims and potentially also with an acr_values parameter. The Curity MFA Approaches article has some notes on this.
It should not be overused. The classic use case is for payments in banking scenarios. If the initial sign in / delegation used a password, the step up request might ask for a second factor, eg a PIN, but should not re-prompt for the password.
CLIENTS AND ACCESS TOKENS
It is awkward for a client to use multiple access tokens. If the original one had scope read then the stepped up one could use scope read write payment and completely replace the original one.
In this case you do not want the high privilege scope to hang around for long. This is yet another reason to use short lived access tokens (~ 15 minutes).
Interestingly also, different scopes the user has consented to can have different times to live, so that refreshed access tokens drop the payment scope.
ADVANCED EXAMPLE
Out of interest, here is an interesting but complicated article on payment workflows in Open Banking. A second OIDC redirect is used to get a payment scope after normal authentication but also to record consent in an audited manner. In a normal app this would be overkill however.
I know that the access token obtained from OAuth2.0 can be used to access protected resources.
OpenID Connect issues ID token and access token after authentication. And the spec says that the access token can be used to access userinfo endpoint to get additional user information.
One thing I'm not able to understand is, is there any difference between the access token obtained in #1 vs #2. If there is no difference then do we need OAuth2.0, if we implement OIDC.
You tend to just implement both OIDC and OAuth 2.0 together as a combined flow, by plugging in an Open Id Connect security library.
Eg For a mobile app it is common to plug in AppAuth Libraries, which would give you this behaviour:
An OAuth 2.0 authorization redirect using response_type=code
The Open Id Connect part is initiated by including scope=openid
You then get an authorization code (OAuth 2.0)
You then swap the authorization code for tokens
You get an access token (the OAuth 2.0 part)
You also get an id token (the OIDC part)
In practical terms OIDC introduces some standardisation that makes developing UI flows and dealing with access tokens in APIs easier, eg:
Metadata endpoint, to tell us where all the other endpoints live
JWKS endpoint, from which we can get the access token's public key
Typically in my own code I do not use the id token much at all. However, it is best practice to receive one, so that libraries such as AppAuth can make extra verification checks against received tokens.
If it helps, my Message Workflow Blog Post summarises some messages and use of endpoints.
This access tokens have different audiences ("aud" claim): the OAuth 2.0 access token is intended for resource server (i.e. API), and OIDC access token is intended for identity server itself.
As for me, they cannot be used interchangebly, but some examples (e.g. IdentityServer4) do that without checking the "aud" claim.
PS. The single access token can be used for both purposes if both audiences are included:
Each principal intended to process the JWT MUST identify itself with a
value in the audience claim.<...> In the general case, the "aud" value
is an array of case-sensitive strings, each containing a StringOrURI
value.
JWT doc
I'm using oauth2 authorization code flow with the ASP.NET core 2.2 AddJwtBearer. My token end point returns JWT access toke with all the claims needed for checking the user's permissions.
I can send this token as the bearer for any Web API call and the standard .net code can use those claims to check permissions eg [Authorize(Policy="somePolicy")].
One of the claims points at an internal session key that we can revoke.
So my question is why would I need an ID token or even a refresh token?
The claims and other details are in the access token so what would an ID token add to this?
Having to use a further call to a userinfo end points send to be a waste if the info is in the Auth token?
If I can revoke the session that Auth token points at, surely I don't need a refresh token and can have longer life Auth tokens?
I've read lots of examples and comparisons but most computations between just oauth2 and enhanced with openid connect seem to be with very basic oauth2 not using JWT etc and so written to exaggerate the differences.
So I'm unclear when both are using the same authorization code flow and JWT tokens, what the team advantages are in using the id token in my situation??
Given your context, it seems that OpenId Connect is not necessary for your situation. It really adds value when you are implementing single sign-on (SSO). In that case the Identity token can also be used on SSO logout.
Having additional claims about the identity in the access token is also a waste. Having to send all this information on each call. Especially when you need the information only once (a Spa may persist the information in memory). It's better to have some api (endpoint) expose the information when requested.
About the access token, you can't revoke it. You may be able to revoke authorization, but the access token remains valid until it expires. You want invalid access tokens to short-circuit as soon as possible in the pipeline, before policies are evaluated.
Please note that it's not a common scenario where the api can revoke access by using an internal session key. Most api's are 'session-less' and fully rely on the access token. Because that's the purpose of a JWT, being self-contained, not having to contact the authority to verify the token.
Perhaps you can use a long-lived access token because in your situation the authorization is determined at another level. But are you capable of detecting when the token is compromised? And where are you going to check it? In every api and client? Or would you rather let the authority take care of it (single responsibility)?
When implementing security you should look at the design, the responsibilities, where to do what. Let the authority, that issues the tokens, take care of authentication and client/resource authorization. The Api, being the resource where the business rules (policies) are implemented, can take care of (user) authorization.
The problem with a long-lived token is that when it falls into the wrong hands, it allows access until it expires or, in your case, until you detect something is wrong. Where a short-lived token always allows access for a short time, making it almost not worthwhile for a hacker to obtain a token for the time it can be used.
With short-lived access tokens you'll have to use refresh tokens. The authority can verify on each call whether a new access token should be issued. Of course here counts the same, this only applies to the situation where you are actually verifying the request. Tokens in itself are not safe. You'll have to add some level of security, e.g. check the ip address. But having the authority to take care of it and using one-time-use refresh tokens already does add security.
In my experience with oidc/oauth2, the access token is mainly used to grant client applications access to a resource (on behalf of a user). Where scope claims define the accessible functionality and the sub claim identifies the user.
Authorization can be implemented on different levels and doesn't have to be part of the access token. In fact, permissions should not be part of the access token at all.
So your setup may be fine. But I wouldn't use long-lived access tokens for the reasons already mentioned. Plus they are not managable. You can't update the access token when someting changes in the flow, e.g. when a scope is added.
Can someone tells me the difference in OAuth2, Auth0, JWT in a concise way and when to use either one and which one is much better?
OAuth2.0 is the name of the protocol you can use to get tokens that can be used to perform an action on behalf of the user. Now these tokens can be used to access some 3rd party API or your own Service.
For example, if you wanted to access someones emails on Outlook for an app you're building, OAuth2.0 allows you to get an Access token (issued by Microsoft) on the end user's behalf (they have to sign in to the identity provider) that can be used in a bearer request (just an HTTP request w/ the Access token).
Highly recommend skimming the RFC to read about the different scenarios OAuth2.0 can be used, the example here is just one case.
JWT (JSON Web token) is the standard format of a token used by many identity providers. Those Access tokens above may come in this format. Here's a small site you can use to decode JWT tokens (try hitting the example token).
Auth0 is a private company that works in the Identity space.
If I have an API secured with Azure Active Directory, what is the flow when an external API wants to talk to my internal API?
Is this just an API to API call as normal or is this a special circumstance and needs handling a different way?
Is this just an API to API call as normal or is this a special circumstance and needs handling a different way?
The special circumstance may depend on the confidentiality of the resources served by these api(s) and the level of security your application needs. In the end it is an api to api call only.
There are two approaches you can use if Azure Active Directory (AAD) is your Identity Provider for the entire application.
Application Identity with OAuth 2.0 client credentials grant provided by AAD. The calling API makes a request to AAD token endpoint with its client id, client secret (credential) and the application id (the unique id for the callee API) to receive an access token as response. This token is used as Bearer token to call the downstream API. In this approach client id, client secret, application id that are exchanged for an access token, are static values. Some one who has access to these values may find a way to compromise application security (highly unlikely).
The second approach is Delegated User Identity with OAuth 2.0. A request is made to AAD token endpoint with client id, client secret, the access token received as part of calling the tier1 API and a special on_behalf_of parameter to receive an access token, refresh token as response. We preferred this approach as it uses a dynamic value (access token from tier1 api) and also provides a refresh token.
You can read more about these approaches here
If you do not want to use AAD, you can use asp.net built in OwinAuthenticationMiddleware to generate and validate your own access tokens. As said earlier it all depends on your application requirements and implementation details, but in the end it is an API to API call.
Hopefully this is helpful, please let me know if you have any questions.
Thank you,
Soma.
oAuth is done for loggin user to a webservice (see also reference here).
Use OAuth to give your users access to their data while protecting their account credentials.
As another webservice wants to consume one of your service best way to do so is to have another authentication method in order to authorize
Other API, I assume you are talking of machines and not users (alias humans).
So best way is to provide another auth mechanism in order to authorize machines to connect to your API in a safe way.
A simple way to do a machine connection is using a private PKI with public/private key.
A good reference for PKI : http://docs.oracle.com/javase/6/docs/technotes/guides/security/certpath/CertPathProgGuide.html