We have our own openid and Oauth2 based authorization server. We have a use case where we want to control the access token issued to expire after one use. This use case is specific to user account. For example user1#client1 should get an access token which should expire after single use whereas user2#client1 should use the default expiration where the token will expire after x seconds but can be used multiple times.
Thanks
Ranjith
There's no built in support for single use in oauth2 or openid-connect, the next generation of Oauth will handle that I think.
But for now I guess your only option is to implement the logic in the API that receives the token. The access token is meant to have a certain lifetime.
the other option is to use reference tokens , then the API needs to ask the token provider on each request. But still you need to cancel it after each use.
Related
I have a refresh token in hand, a client_id and a client_secret.
I'd like to determine which end-user the refresh token corresponds to, and/or which scopes.
Is that possible, and, if so, what's the best way to go about that?
Most commonly refresh tokens are opaque unreadable values that map to state stored in the Authorization Server.
Some providers may issue refresh tokens as JWTs, in which case you can read the values. Your code will not be portable though, so this is not advised.
CLIENT
Usually an OAuth client gets a refresh token from the Authorization Server (AS) after user authentication. Later on the client can try to renew access tokens with it.
AUTHORIZATION SERVER
This is the standard component for issuing and renewing refresh tokens and the typical behaviour is like this:
When a user authenticates, record details of the 'delegation' in a database row
Typical fields stored are a SHA256 hash of the refresh token, the user and client IDs, and the issued / expiry times of the grant
This information enables the AS to receive and validate token refresh requests.
ISSUING YOUR OWN REFRESH TOKENS
This should only need to be done if you don't have an AS. In this case follow the AS pattern above. It is recommended instead to use an AS to do it for you though - eg the free edition of Curity from the above link.
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.
I tried to add YouTube Video from the third party and After one day, I got the success in doing so. But While uploading a video the access token is required and in order to get that access token the user must be logged in. And the expiration time for that access token is 3600 seconds( 1 hr).
Now, There are some of my questions regarding this.
Is there anyway, by which I can refresh access token.
If some one has G Suite account, then Is there any special values for expiration time, or it remains the same?
As per the documentation, I can have maximum 50 tokens, So is there any alternative for it, So that I can get valid token after 50 requests.
To answer your question for number 1, you can check the documentation here.
Access tokens periodically expire. You can refresh an access token
without prompting the user for permission (including when the user is
not present) if you requested offline access to the scopes associated
with the token.
If you use a Google API Client Library, the client object refreshes the access token as needed as long as you configure that
object for offline access.
If you are not using a client library, you need to set the access_type HTTP query parameter to offline when redirecting the
user to Google's OAuth 2.0 server. In that case, Google's
authorization server returns a refresh token when you exchange an
authorization code for an access token. Then, if the access token
expires (or at any other time), you can use a refresh token to obtain
a new access token.
Requesting offline access is a requirement for any application that
needs to access a Google API when the user is not present. For
example, an app that performs backup services or executes actions at
predetermined times needs to be able to refresh its access token when
the user is not present. The default style of access is called online.
About the G Suite account, it was stated 24 Hours in the documentation. Note:
In this SO post answer, the function of Access Token and Refresh Token was discussed.
I am not sure if there are ways to alter the limits because of security reasons.
To clearly differentiate these two tokens and avoid getting mixed up,
here are their functions given in The OAuth 2.0 Authorization
Framework:
Access Tokens are issued to third-party clients by an authorization server with the approval of the resource owner. The
client uses the access token to access the protected resources hosted
by the resource server.
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.
For a B2B REST API servicing Enterprise clients who may have multiple applications using a Client ID/Secret:
If you send a request for an oAuth2 access token for a specific Client ID and Client Secret and receive an access token then later on send another request for a token with that same Client ID/Secret, should that invalidate the previous access token?
In other words, in this case, should a Client ID/Secret be able to request and use multiple valid access tokens? Are there different cases where this should be implemented or not?
OAuth2 is generally about a user delegating access to a client, so in the case where a client has many users (as it usually will), it will most definitely be using multiple access tokens since they will apply to different users.
Consider the situation where you grant access to your Google account to another online application (the client). Google issues an access token which might allow the client to read your contacts, for example, using Google's OAuth2 APIs (with your prior approval). Obviously it can only access your contacts with this token, not other people's. Google may issue many different access tokens to the same client, but each may correspond to a different user and/or resource.
The same authorization server may issue tokens for many different resources, so even in the case where there is no interaction with a user (as in the "client credentials" grant), a client may still need to manage multiple tokens.
Whether the authorization server invalidates a token when another is requested for the same user, audience, scope etc., would be implementation dependent. A client wouldn't usually need to do this and would normally use a refresh token to obtain a new token when its existing one was about to expire. I'd say it's generally more important that a user can invalidate existing tokens they have authorized, and that tokens can be invalidated for a particular client. Of course, this also requires that the resource server has some way of checking for token revocation before granting access.
Yes, a client can have several access tokens. It's meaningful, we're actually using.
Consider that tokens may have different scopes, so a client may have a token with scope "res1" for a resource and a another token with scope "res2" for a different resource.
Another use case may be to request a refresh token with several scopes, e.g. "read write" and use it to get a "read" scoped access token to initialize a management GUI, then get a new access token for each write transaction.
You can argue whether it's good design/implementation or not but it's definitely technically possible and not forbidden by the standard.
I read the documentation in the Youtube developers website it does not talk about any validity.
Does the OAuth 2.0 standards define any validity period or is the authorization token valid till the user revokes it manually ?
The OAuth spec defines that the token should expire shortly after its granted, so will it expire after I get the
access and refresh tokens ?
And can I use this access token for all future API requests or do I need to get a new token periodically ?
I'm assuming you are talking about the authorization code, you're mixing the terms a bit here.
From the OAuth 2.0 draft:
The authorization code MUST expire shortly after it is issued to mitigate the risk of leaks. A maximum authorization code lifetime of 10 minutes is RECOMMENDED. The client MUST NOT use the authorization code more than once. If an authorization code is used more than once, the authorization server MUST deny the request and SHOULD revoke (when possible) all tokens previously issued based on that authorization code.
After using it once for getting the access token, you can not use it again. You also don't need to retrieve an authorization code periodically. You do this only when you have no access token for a user, but want to request his data.
Your access token some time expires. You know when by either looking at the expires_in value that got send with it, or by doing a request to the API and getting an access token expired error back. Then you can use the refresh token to get a new access token without the user being involved.
Very useful step-by-step guide about how to get access and fresh tokens and save them for future use using YouTube OAuth API v3.
PHP server-side YouTube V3 OAuth API video upload guide.
The good thing is, you do not need to worry about the expiry of the tokens, as the script in this guide checks, saves, and updates the token in a txt file for future access.
{"access_token":"XXXXXXXXX","token_type":"Bearer", "expires_in":3600, "refresh_token":"XXXXXXX", "created":000000}
We use at http://presentationtube.com and it works fine with thousands of users.