I'm trying to find anything in the OAuth2 specs that relate to the lifespan of the Authorization Grant. There is mention of the Access Token expiring and needing to be refreshed/renewed but I didn't see anything about the Grant. My impression is that if there is a need to expire or revoke an Authorization Grant, this would be something that would have to be added to the Auth Server and is not really within the scope of the OAuth2 framework.
Am I correct in my understanding or have I overlooked something? Is this even a valid use-case?
RFC 6749 (The OAuth 2.0 Authorization Framework) mentions that:
Authorization codes MUST be short lived and single-use.
RFC 6819 (OAuth 2.0 Threat Model and Security Considerations) provides more detailed description:
Browser-based flows expose protocol parameters to potential attackers via URI query parameters (HTTP referrer), the browser cache, or log file entries, and could be replayed. In order to reduce this threat, short-lived authorization "codes" are passed instead of tokens and exchanged for tokens over a more secure direct connection between the client and the authorization server.
However there is no exact information about grant token lifespan in RFCs. From my experience it may be a minute or several.
Related
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
In OAuth2.0 Authorization Code Grant as stated in RFC 6749, the token request requires client secret according to sec4.1.3; however, the authorization request is not according to sec4.1.1.
Does anyone know why? It seems using client secret for both authorization and token request makes the process more secure.
They are different because they are two different types of requests. 4.1.1
GET /authorize?response_type=code&client_id=s6BhdRkqt3&state=xyz
&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1
Host: server.example.com
Is used to display the actual consent screen to the user.
Once the user has accepted then the code is exchanged for an access token
>HTTP/1.1 302 Found
Location: https://client.example.com/cb?code=SplxlOBeZQQYbYS6WxSbIA
&state=xyz
No secret is needed because you are currently in the Authorization Code section of the document.
4.1. Authorization Code Grant
The authorization code grant type is used to obtain both access
tokens and refresh tokens and is optimized for confidential clients.
Since this is a redirection-based flow, the client must be capable of
interacting with the resource owner's user-agent (typically a web
browser) and capable of receiving incoming requests (via redirection)
from the authorization server.
Authorization Code is sometimes refereed to as the Implicit flow, as the required access token is sent back to the client application without the need for an authorization request token. This makes the whole flow pretty easy, but also less secure. As the client application, which is typically JavaScript running within a Browser is less trusted, no refresh tokens for long-lived access are returned. Returning an access token to JavaScript clients also means that your browser-based application needs to take special care – think of XSS (Cross-Site Scripting) Attacks that could leak the access token to other systems.
Basically a user implicitly trusts their pc so there is really no need for the client secret validation step. Client secret is only needed for server sided applications where the user does not have access to the server so the server must validate itself.
I've been trying to learn some server side frameworks these days. I am not an expert of oauth2, but I had use an api with a team. They gave me an access using Resource owner credentials grant, with a grant_type as password, client_id and client_secret. I can log in on multiple browsers at the same time. As I have tried sails js oauth 2 and laravel passport oauth2. I got confused. Both of them using grant_type password revoke my old access_token. Using laravel passport and sails js oauth2 with grant_type password. I can log in only on one device or browser at a time. I'm confused which one is the right thing to do.
Is this how oauth2 really works? you can only log in and use one access token?
If this is the standard way, revoking the old access token. What type of grant type should I use. so my multiple devices can log in at the same time?
The behavior --- whether issuing a new access token invalidates existing access tokens or not --- depends on OAuth 2.0 server implementations. The OAuth 2.0 specification (RFC 6749) does not impose any restrictions on the behavior.
In fact, a certain OAuth 2.0 server implementation provides a feature to enable server administrators to configure the behavior. The following is a screenshot of the description about the configuration item ("Single Access Token Per Subject").
So, what matters is not grant_type but the implementation policy of the OAuth 2.0 server you are using.
I have very little experience with Oauth 2.0 and am trying to better understand how the system works. Are access tokens tied to a user/device/session? For example, can I migrate an access token granted for one app and use it in another app? How will the server/API know? I believe most APIs have apps request using an app_ID, is there any other data that goes into a request for a token?
Thanks!
The OAuth 2.0 protocol framework is designed to allow for different types of access tokens but the only access token that has been standardized so far is the so-called "Bearer" token, so I'm assuming your question is about that.
A Bearer token is opaque to the Client which means that it is just an "identifier" or "string" that the Client passes on to the Resource Server to get access to protected resources. This also means that it is not specifically tied to a device/session or Client. In fact anyone who gets a hold of the Bearer token can actually use it to get access to the protected resources. This is one of the known drawbacks of Bearer tokens but it makes it very easy to implement them. It relies on a secure HTTPs channel for confidentiality.
The previous paragraph describes how to use a Bearer token. The process that the Client has to go through to obtain such a token, may include presenting a Client identifier and a Client secret to the Authorization Server indeed. But the Resource Server (aka. Server or API) does not know or care how the Client obtained the Bearer token.
There are token extensions of OAuth 2.0 under development that would require the Client to proof that it is the rightful owner of the token. Such tokens are called "Proof of Possession" Tokens and may be useful in environments that have higher security requirements. See: http://www.thread-safe.com/2015/01/proof-of-possession-putting-pieces.html
The OAuth2 JWT Profile introduces the possibility to use JWTs both as authorization grant and as client authentication.
The JWT client authentication feature is independent of a certain grant type, and can be used with any grant type, also the client credentials grant.
However, using the JWT grant type seems to do exactly the same as using the client credentials grant with JWT client authentication, except that the syntax is slightly different.
In both cases the client contacts the token endpoint to get an access token:
POST /token.oauth2 HTTP/1.1
Host: as.example.com
Content-Type: application/x-www-form-urlencoded
grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Ajwt-bearer&assertion=[JWT]
vs
POST /token.oauth2 HTTP/1.1
Host: as.example.com
Content-Type: application/x-www-form-urlencoded
grant_type=client_credentials&client_assertion_type=urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertion-type%3Ajwt-bearer&client_assertion=[JWT]
A slightly different perspective on the great answer by Josh C: as it happens both the client authentication and the grant credentials can be expressed as JWTs but the semantics behind them are different.
It is about separation of concerns: clients authenticate with a credential that identifies them i.e. they are the so-called subject whereas they use grants that were issued to them i.e. they are the so-called audience. Or as version 12 of the draft spec (https://datatracker.ietf.org/doc/html/draft-ietf-oauth-jwt-bearer-12) says:
The JWT MUST contain a "sub" (subject) claim identifying the
principal that is the subject of the JWT. Two cases need to be
differentiated:
A. For the authorization grant, the subject typically
identifies an authorized accessor for which the access token
is being requested (i.e., the resource owner or an
authorized delegate), but in some cases, may be a
pseudonymous identifier or other value denoting an anonymous
user.
B. For client authentication, the subject MUST be the
"client_id" of the OAuth client.
Probably very little. The way a client is identified and the way auth grants are requested are two different notions in OAuth, so the questions address those notions separately:
Can a client authenticate with an authorization server using a JWT? Yes.
Can a client make a grant request using a JWT? Yes.
The spec seems to hint that the separation is simply a design decision, deferring to policy makers to find what scenarios are valuable to them:
The use of a security token for client authentication is orthogonal to and separable from using a security token as an authorization grant. They can be used either in combination or separately. Client authentication using a JWT is nothing more than an alternative way for a client to authenticate to the token endpoint and must be used in conjunction with some grant type to form a complete and meaningful protocol request. JWT authorization grants may be used with or without client authentication or identification. Whether or not client authentication is needed in conjunction with a JWT authorization grant, as well as the supported types of client authentication, are policy decisions at the discretion of the authorization server.
One concrete possibility: The separation could allow for an authorization server to set up different policies along client types. For example, in the case of a public client (like a mobile app), the server should not accept the client creds grant type. Instead, the server could accept the JWT grant type for public clients and issue a token of lesser privilege.
Other than that, I would suppose that the design simply offers a degree of freedom for clients and servers to pivot around--keep this part of the existing handshake the same while migrating this part--as the need arises.