When you authenticate with an OIDC provider you get back an id token and if you specified scopes for an API you get back an access token so that client applications can make requests to protected resources on the end user's behalf. Typically the access token is also a JWT.
But what is to stop someone from spoofing one of these access tokens, and creating one and passing it to an API? I understand there are safeguards to prevent modification because the signature will be different than what any validation logic is expecting, but what if a malicious user created a brand new one manually? Especially because these tokens can be validated 'in place' by any API that requires an access token (not all API's use the introspection endpoint... especially with a JWT). I do understand there is metadata around the signing keys for JWT's from OpenID Connect providers and that it is available in the OIDC discovery document. For example, here is Google's JWK metadata. Given that you have signing information publicly available, and JWT access token's can be validated without any requests to the OIDC provider, how are JWT's secure? What is preventing a person from creating one and passing it as a bearer token to an API that requires an access token?
But what is to stop someone from spoofing one of these access tokens, and creating one and passing it to an API?
Spoofing and reconstruction of signature is nearly impossible without the private key (assuming you are using asymmetric signing algorithm like RS256) that used for signing the original JWT.
The JWK information available via OIDC discovery document only contains the public key.
Also Use HTTPS for authorization / token exchange to avoid token sniffing.
Related
I'm learning about access tokens and refresh tokens. I understand...
An access token is an artifact that proves the user has been authorized to access a resource and allows a client application to perform specific actions on behalf of the user.
A refresh token is an artifact that lets a client application get new access tokens without having to ask the user to log in again.
I don't understand the following paragraph from this JWT book:
The key aspect of the separation between access and refresh tokens lies in the possibility of making access tokens easy to validate. An access token that carries a signature (such as a signed JWT) may be validated by the resource server on its own. There is no need to contact the authorization server for this purpose. Refresh tokens, on the other hand, require access to the authorization server.
The text is referring to the following image:
What exactly does "validate" mean here? How can the resource server validate the access token on its own? If the authorization server generates the access token, which it does in this case, isn't the authorization server required to validate the access token?
The only thing I can think of is that the resource server has a copy of the key used to sign the access token (see here). If so, doesn't that render the authorization server redundant?
JSON Web Tokens can be validated because, as you guess correctly, the resource server will have beforehand the public key of the private key that was used to sign that token. It means, that if someone in the middle tried to tamper the JWT, the validation will fail and the JWT should not be processed.
Also, the JWT contains fields as the expiration time that can be checked by the resource to understand if the token is still valid or not.
I am building an application that spans over several parts of infrastructure.
An end-user can sign in to a portal using OAuth 2.0 authorization code flow. When calling different APIs, the portal requests tokens on-behalf-of the signed in user and attaches those to outgoing requests. The tokens received to call external APIs have an aud claim matching the target API.
When a call to an external API is fired, it first passes through an API Gateway. This API Gateway validates the token and ensures the aud claim is actually intended for this endpoint. It also verifies roles and a few other claims.
When the gateway checks pass, the request is forwarded to the actual implementation. Now the actual implementation also verifies the token, but only that the token is valid (e.g. not looking at specific claims). That is not to say that the claims aren't used internally in the application after the token is validated, roles are very much part of the application logic.
So to summarize this as bullet points:
User signs in to portal
User performs some action that causes an API call
Portal attaches token to outgoing request
Request hits gateway for 1..n claims are validated
Request is forwarded to actual implementation
Implementation again validates token is valid, not looking at claims
All endpoints are public, e.g. I could call any of these from anywhere as long as I have a token.
In the above outlined scenario, I'm handling the token properly?
In general, what is the recommendation for tokens passing through several layers of an application? Should every layer validate the token? If yes, are there exceptions to the rule?
Typically, JWT tokens are validated when are sent from the client-side to the server-side. As these tokens are signed, if anyone tries to tamper with the token before sending it to the server-side endpoint, the token verification will fail, therefore these tokens are a secure way of sending the session of an authenticated user to an API or a server endpoint.
These JWTs can be also transferred between servers or different application layers, and it always would be a good practice to verify the token before processing it. It is adding a layer of security to avoid anyone sending tokens to that layer directly and skipping the validation.
The issue I have with JWT tokens is in the event the token is stolen. Now I have a session that is linked to the token in the back end. I do save the user's IP address when the token is first generated.
The issue is that, because of mobile phones and cellular networks, the IP can change while the end user is using the web app, so I cannot enforce an IP verification. I do a UUID check but since the UUID is passed with the token, obtaining the token also means obtaining the UUID.
Is there any way to secure JWT tokens for the case they get stolen?
Yes, there is a way to protect tokens from being used by a malicious party. There is a concept of "sender-constrained tokens". These are access tokens which require the sender to present some kind of proof of possession of the token. Such a token, is no longer a bearer token, meaning that it can only be used by the original client, not by anyone who manages to steal that token. There are different way to implement sender-constrained tokens (sometimes also called proof-of-possession tokens). E.g. you can use mTLS constraint, which is reliable but a bit harder to implement, or a standard called DPoP - Demonstration of Proof-of-Possession. The latter one doesn't require you to deal with Public Key Infrastructure.
Well, in OAuth2 specification is foreseen cases where you are authenticating in an application that runs fully on the client side (browsers, mobiles, etc.) and so they are incapable of protecting their code/data.
In the memo regarding Security Considerations they say you should not store credentials in our code (for obvious reasons, I think):
https://www.rfc-editor.org/rfc/rfc6819#section-5.3.1
Also, in the memo about native clients, they highly recommend that an authorization server do not require an application secret:
https://www.rfc-editor.org/rfc/rfc8252#section-8.5
So, it should be possible to obtain an access token without using the client secret using a "client" grant type, like this:
https://www.oauth.com/oauth2-servers/mobile-and-native-apps/authorization/
Anyway, in the Github documentation, it's stated that the client_secret is mandatory to retrieve the access token:
https://developer.github.com/apps/building-oauth-apps/authorizing-oauth-apps/#2-users-are-redirected-back-to-your-site-by-github
By the official specification, you should be able to achieve this, but I couldn't find a way to achieve that using the Github OAuth, and here is my question:
Is there a way to use Github OAuth getting an access token without using the client_secret?
So, is there a way to use Github OAuth, get an access token without using the client_secret?
Not that I can see, when considering the authorization grant step
The application exchanges that code for the access token.
When the application makes the request for the access token, that request is authenticated with the client secret, which reduces the risk of an attacker intercepting the authorization code and using it themselves.
That means, if an application needs to automate that step on behalf of client, it needs to fetch that secret from a third-party referential, like a vault.
See for instance puppetlabs/vault-plugin-secrets-oauthapp, which is a plugin providing a secure wrapper around OAuth 2 authorization code grant flows, allowing a Vault client to request authorization on behalf of a user and perform actions using a negotiated OAuth 2 access token.
(here, Valut is hashicorp/vault)
I have two different REST API’s say Authentication API & Business API hosted in Windows azure.
Authentication API is responsible for authenticating user using WsFederation or OpenID or custom authentication
Business API is responsible for executing business logic. Only legitimate user should be able to access this API.
Client will contact first Authentication API and will acquire the token and then it will pass that token to Business API.
Since client can send any token to business API. Business has to validate the token. It simply cannot trust on the token. Since token Is generated by Authentication API, how business API will validate the token.
What is a standard way to validate the token in such scenario where Authentication API and Business API are hosted separately?
Good References
Principles of Token Validation (Vittorio's blog) - Awesome article, most of the information is generic so applies with or without Azure AD, and it's coming from a very knowledgeable author of course
Manually validating a JWT access token in a web API - This one is specific to validating an Azure AD issued token. Has complete code implementation too. You don't need to do exactly this, because your validation will depend on token format/claims that you use but may provide a helpful reference.
You can look at how token validation is recommended for applications secured by Azure Active Directory as a case study (and may be some other systems as well), then decide what works best for your case.
Brief explanation on how Azure AD example is relevant.. as validating received token is required just like in your case
When you develop any web API (or web app) secured by Azure Active Directory and use bearer token based authentication, the way things flow is very similar to what you explain above with your 2 APIs (just for understanding purpose, your authentication API is doing what Azure AD token endpoints would do.. i.e. provide a valid token).
To access the secure web API, calling application/client first interacts with Azure AD endpoints to get a relevant token for required resource, then it sends a request for actual resource along with the token in Authorization header to the web API. Now, the first thing web API does is to validate this token and only if everything is correct continue with execution to eventually return a response. I hope this matches at a high level with your flow.
What to validate?
1. Token Signature
The key used to sign the issued token is uniquely associated to the issuing authority, so nobody else can issue a token with your Authority's signature.
a. This helps to check that the token was in fact issued by Azure AD (or in your case your trusted STS, using the Authentication API you mention).
b. This also makes sure that since the token was issued and till it reached your web API, no body has tampered with it. If any attempt is made to change any information in the token, the signature will break.
2. Token Claims
This will depend on what claims/information you send as part of the token (for example, if same Authentication API issues tokens for multiple different APIs, then something like audience and issuer might make sense for you as well. Token validity time period using something like nbf and exp below are also pretty generic)
Taking Azure AD issued tokens as example here are the important ones that should be validated:
audience claim (aud), to verify that the token was intended to be given to your application
not before (nbf) and expiration time (exp) claims, to verify that the token has been received within it's validity period
issuer claim (iss), to verify that that token was in fact issued by the said authority. Notice this is a second way, apart from signature for the same purpose and generally both signature and issuer check are used together. (See Vittorio's blog)
nonce, as a token replay attack mitigation
tenant claim (tid), to verify the tenant. This is useful in case of multi-tenant applications.
Sample JWT Token from Azure AD
Actual Value: eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1N... (a long encoded string continues) Decoded Value (you can check this easily using a website like https://jwt.ms or https://jwt.io):
{
"aud": "https://service.contoso.com/",
"iss": "https://sts.windows.net/7fe81447-da57-4385-becb-6de57f21477e/",
"iat": 1388440863,
"nbf": 1388440863,
"exp": 1388444763,
"ver": "1.0",
"tid": "7fe81447-da57-4385-becb-6de57f21477e",
"oid": "68389ae2-62fa-4b18-91fe-53dd109d74f5",
"upn": "frankm#contoso.com",
"unique_name": "frankm#contoso.com",
"sub": "deNqIj9IOE9PWJWbHsftXt2EabPVl0Cj8QAmefRLV98",
"family_name": "Miller",
"given_name": "Frank",
"appid": "2d4d11a2-f814-46a7-890a-274a72a7309e",
"appidacr": "0",
"scp": "user_impersonation",
"acr": "1"
}
How to do token validation?
Make use of standard libraries as much as possible. See the code implementation sample Manually validating a JWT access token in a web API. This one makes use of JwtSecurityTokenHandler.ValidateToken Method (JwtSecurityToken). Your case will depend on your token format/implementation etc.