I am implementing the oauth2 client credentials flow. When Auth server is called to get token... I return a jwt token including also scopes into it (e.g. read:orders and write:orders) and as audience the api identifier (.. /serv/api/v1/orders). When I use then token I pass it in authentication header as Bearer token. When I check if token is valid I check expire date.. If the API called is the same of audience and if the endpoint called has a scope included in my token. If server side I delete scope (e.g. I remove write:order scope) the previous token also contains the write scope. Actually the only thing I do is to wait token fails and when I get a new token I will don't have the write scope.
How can I invalidate the previous token before expiration?
Should I check scope server side during token validation? In this case I suppose is useless to register scopes into token.
Thanks for help.
If you need to invalidate tokens before expiration date then you have to keep track of the issued tokens in your Authorization Server, mark those which should be invalidated, and then make the API verify the token by making a request to the Authorization Server.
As you've pointed out, in such a setup there is not much use of the scopes in the token. I would suggest to use an opaque token instead of a JWT as your access token. Then have your API perform token introspection - which is a standardised operation in OAuth. The Authorization Server will return scopes corresponding to your token, or 404 if the token has been invalidated.
Related
Currently I am using /token endpoint to obtain an access token, an ID token (by including the openid+offline_access scope), and a refresh token for the Authorization Code flow. The value for code is the authorization code that I receive in the response from the request to the /authorize endpoint.
Also to refresh access token as well as an ID token, I am sending a token request with a grant_type of refresh_token.
Below is the reference link, I am trying similar to implement in my custom OIDC application.
https://developer.okta.com/docs/guides/refresh-tokens/main/#renew-access-and-id-tokens-with-spas
Does it suppose to return both refresh_token and id_token OR both are optional if grant_type=refresh_token (also in token endpoint openid+offline_access scope added) in OpenID Connect concept?
Below is the link I am trying to understand.
https://openid.net/specs/openid-connect-core-1_0.html#RefreshTokens
When you use the refresh token, the purpose is to get a new access token. Optionally, depending on the backend configuration, you might get a new refresh token as well (if you use a one-time refresh token setup).
You never get a new ID-token back, the ID token is usually a very short-lived token (like 5 minutes) and its main purpose is to describe how the user is authenticated and who it is. The main purpose of the ID token is to create the local session (typically a session cookie), after that the ID token has no real use.
I am implementing an OAuth2 server that supports refresh token however, there is something that I am not been able to understand fully.
When a user request for a new access token via the refresh_token grant_type and he/she requested lesser scope (3 out of the 5 scopes) than what the original access token has. Should the refresh token have the original scopes or should the refresh token have the new scopes requested?
If the refresh token has the new scopes requested, does this mean that eventually, they will run out of scopes if they keep requesting lesser scopes?
Should the refresh token keep the original scopes? This would mean that an access token returned would have different scopes as to what is stored in the refresh token, and the next request to get a new access token may result in more scopes than the current access token.
Can someone please enlighten me on this issue?
I have read the RFC docs and there is a point that states
If a new refresh token is issued, the refresh token scope MUST be
identical to that of the refresh token included by the client in the
request.
For a refresh token grant:
The base behaviour is to receive only a new access token in the response
The original refresh token is then reused a number of times.
Some authorization servers support refresh token rotation and may also:
Issue a new 'rolling' refresh token
This is bound to the original scopes and session time
At least that's the theory, though you need to test for your particular authorization server. Vendor support from the likes of Microsoft, AWS and others varies considerably.
when client requests resource with jwt-token, first resource need to verify token. In simple scenario , resource server verifies itself. But there are cases when oauth server is called to verify the token.
So my question is, why oauth server could be called to verify the token?
It all depend's on how you are using validating token.
Methods used for validating token
Introspection
This is a method to get actual token information via special endpoint
directly from the Authorization Server. Token information usually
includes token type, status (active or not), user, client identifier,
available OAuth2 scopes, and expiration time.The method requires
direct interaction with Authorization Server for every token
validation. It has high safety but low performance.
Token validation by signature (JWT tokens only).
This is a method when the token is validated according to its
cryptographic signature and all required token information is received
from token itself. It means that token validity is verified without
interaction with an Authorization server, and if the token was revoked
before its expiration, we’ll never know about it. So, this method is
fast but less secure than introspection.
You can have more details on token validation on https://dzone.com/articles/oauth2-tips-token-validation
I am new to OAuth2, was thinking about the scenario where Access Token if stolen, can access resources from the service it is provided. how OAuth2 prevent it other than making it short interval expiration for access JWT Token.
It can't really, if the token is a simple bearer token. As described in the spec, the client could be made to authenticate when using an access token:
Additional authentication credentials, which are beyond
the scope of this specification, may be required in order for the
client to use a token
but that isn't usually done in practice.p
The token doesn't have to be a JWT - depending on the implementation, it's possible that a token revocation mechanism may also be in place which could be used if it was known that a token was stolen.
Tokens should be protected and only sent over HTTPS (a requirement of the spec).
I'm looking into Oauth2 to allow developers to authorize users of their app to use my service. I've found a few sources that say that my Authorization Server should return an access token when a user sends an assertion (JWT in my case) but that it should not return a refresh token. I'm wondering what the harm is in returning a refresh token. Developers could invalidate refresh/access tokens by calling an Api that invalidates any access granted from a particular JWT's id.
That recommendation is not correct. Refresh tokens are optional and can be issued at the discretion of the Authorization Server after client presents the authorization grant. See Oauth2 specification
1.5 Refresh tokens
Refresh tokens are credentials used to obtain access tokens. Refresh
tokens are issued to the client by the authorization server and are
used to obtain a new access token when the current access token
becomes invalid or expires, or to obtain additional access tokens
with identical or narrower scope (access tokens may have a shorter
lifetime and fewer permissions than authorized by the resource
owner). Issuing a refresh token is optional at the discretion of the
authorization server. If the authorization server issues a refresh
token, it is included when issuing an access token (i.e., step (D) in
Figure 1).