It may be a stupid or naive question, but: Are OAuth2 bearer tokens signed?
To put it in other words: Is the consumer able to verify whether the bearer token was issued by a specific authorization server?
No. But there are efforts under way to fix this. HTTPS ensures the token was transmitted securely, but it doesn't tell you who issued the token.
Actually you have to use oauth over https which is going to be responsable of signing
Related
I'm attempting to implement a security solution for a micro-services architecture. My authentication server supports OAuth2 and OIDC.
I'm trying to figure out if I can pass a JWT token between my micro-services to avoid having to repeatedly exchange an opaque token to get the user's claims. There's nothing (practical) that stops me doing that. I can:
Use the JWT (ID token) I get from the auth server as a bearer token when making the calls.
Each service can validate that token against the auth server's (cached) JWKS to make sure it's valid
Each service can include the token on it's calls to other services
I've read that it's ok for an access token to be a JWT.
Great, but:
My (moral?) issue is this:
A JWT is intended for a specific audience. In fact the spec basically says that if it's not for you, you should reject it.
A Bearer token is intended to be non-audience specific. So if I issue a token that says that the bearer can read my mail, it can get passed through half a dozen different services, any one of which should be able to read my mail.
So my question is simply, how can a JWT be a bearer token?
Bonus points for links to any nice articles/videos/examples of an effective distributed authentication solution!
A JWT is intended for a specific audience. In fact the spec basically says that if it's not for you, you should reject it.
This is the case also for a bearer token. It can be passed on by anyone, but only the audience should act on its validity.
So, service X can get a JWT bearer token with intended audience service Y. It will not give the calling client any authorization based on that, but calling service Y with it does not violate the audience claim. What would violate the audience claim is if service X validates the JWT, seeing the mismatching audience and says "Well, since the client has a JWT stating that it is user Fubar, I can return some info about user Fubar.".
The difference for an opaque non-JWT bearer token is that service X would have no way to misuse it...
I'm new in Oauth 2.0, I'm trying to understand the differences between bearer-token and a "Classical" token.
Is also the refresh-token a bearer one?
A refresh token is used to get a new bearer token. So they are different. I have am not sure what you mean by a "Classical" token.
This is a good introduction to tokens
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.
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
I'm trying to implement the Resource Owner & Password Credentials flow from the OAuth 2 spec. I'm having trouble understanding the token_type value that gets sent back with a valid response. In the spec all the examples show "token_type":"example" but says it should be
token_type
REQUIRED. The type of the token issued as described in
Section 7.1. Value is case insensitive.
Can someone please explain this to me?
token_type is a parameter in Access Token generate call to Authorization server, which essentially represents how an access_token will be generated and presented for resource access calls.
You provide token_type in the access token generation call to an authorization server.
If you choose Bearer (default on most implementation), an access_token is generated and sent back to you. Bearer can be simply understood as "give access to the bearer of this token." One valid token and no question asked. On the other hand, if you choose Mac and sign_type (default hmac-sha-1 on most implementation), the access token is generated and kept as secret in Key Manager as an attribute, and an encrypted secret is sent back as access_token.
Yes, you can use your own implementation of token_type, but that might not make much sense as developers will need to follow your process rather than standard implementations of OAuth.
Anyone can define "token_type" as an OAuth 2.0 extension, but currently "bearer" token type is the most common one.
https://www.rfc-editor.org/rfc/rfc6750
Basically that's what Facebook is using. Their implementation is a bit behind from the latest spec though.
If you want to be more secure than Facebook (or as secure as OAuth 1.0 which has "signature"), you can use "mac" token type.
However, it will be hard way since the mac spec is still changing rapidly.
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-http-mac-05
From RFC 6750, Section 1.2:
Bearer Token
A security token with the property that any party in possession of the token (a "bearer") can use the token in any way that any other party in possession of it can. Using a bearer token does not require a bearer to prove possession of cryptographic key material (proof-of-possession).
The Bearer Token or Refresh token is created for you by the Authentication server. When a user authenticates your application (client) the authentication server then goes and generates for your a Bearer Token (refresh token) which you can then use to get an access token.
The Bearer Token is normally some kind of cryptic value created by the authentication server, it isn't random it is created based upon the user giving you access and the client your application getting access.
See also: Mozilla MDN Header Information.