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
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 have done a sample application using Sprint Boot, Spring security and JWT and define my custom authentication & authorization filters. While performing basic authentication (passing username & password) I get JWT token in the format of xxxx.yyyy.zzzz where xxxx is header, yyyy is payload and zzzz is signature and each part is encoded using Base64URL encoder. What I do not understand is how JWT is different from OAuth 2.0. In OAuth 2.0, we can pass 2 types of grant_types as either 'username' or 'client credentials' & also needs to pass client id, secret id to get access & refresh tokens.
Please assist to clarify my following doubts:-
1) Is JWT lighter than OAuth 2.0 as it does not contain the refresh token but just access token?
2) Is JWT cannot be used to make a standalone authorization server like we can make a standalone authorization server using #EnableAuthorizationServer annotation when it comes to OAuth 2.0. Is my assumption correct?
3) JWT does not accept client id/secret client but just used as basic authentication to get bearer tokens?
4) Is the format of access token (or bearer) for both OAuth2.0 and JWT are different?
I have seen an example where both OAuth 2.0 and JWT were used. OAuth 2.0 was to make authorization server which returns JWT token only in the end but did not understand why JWT was used if OAuth2.0 can return a token by itself.
Thank you
JWT is a JSON-based token defined in RFC 7519. OAuth 2.0 is an authorization framework defined in RFC 6749. Comparing both is like asking "How Glucose is different from Apple Pie?".
However, it is possible to bring OAuth 2.0 and JWTs together as is defined in RFC 7523 – The JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants. It standardizes, how to use JWTs as bearer tokens within the OAuth 2.0 framework, which enables what I call stateless authentication.
Regarding your questions:
Whether or not you use JWTs as bearer tokens does not influence whether or not you want to hand out refresh tokens.
Not sure whether I get your questions. However, using JWT allows you to do decentral, stateless auth decisions as there is no necessity to store token state centrally. However, nobody prevents you from having a standalone authorization server.
How you want to do authentication has nothing to do with JWT. It is still OAuth 2.0.
In OAuth 2.0 bearer tokens are considered to be opaque tokens – the format does not matter. If you use JWTs as bearer tokens, you need to follow the corresponding RFC.
The OpenID Connect Spec OAuth 2.0 Multiple Response Type Encoding Practices states that multiple response_type can be combined, e.g. response_type="code token". Now I'm wondering what it's good for to request an authorization code and the token. Isn't the auth code superfluous if you have the token already?
OAuth 2.0 is a protocol framework on top of which other protocols can be built and OpenID Connect is an example of such a protocol.
Especially for OpenID Connect it makes sense to use combined response types because there are 2 tokens in play: the access_token and the id_token. Using "response_type" the client can request how each of the tokens should be delivered.
In the example that that you give, the access_token will be delivered through the front channel as part of the authentication response but the id_token will be delivered when exchanging the "code" for an id_token at the token endpoint in a backchannel call.
A reason for doing this may be that the id_token, which is a signed JWT, does not have to be verified locally when obtained from a proper TLS protected token endpoint, so the client code can be simple. The access_token is opaque to the client anyhow and does not benefit from that.
I've never seen this used in practice. Yes, having the token already kind of diminishes the value of using the code flow.
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
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.