If I have a JWT token generated by a ruby-on-rails application, would it be possible to decrypt that token in another framework/language like go?
This is assuming the JWT token is using the same algorithm and secret key etc.
You should be able to decode your token if the framework respects the https://www.rfc-editor.org/rfc/rfc7519.
Related
We have an OAuth server that uses doorkeeper. We want to start using doorkeeper JWT, but we can't turn it on for all OAuth clients yet as some are out of our control and we are pretty sure they are storing the access tokens their apps receive in a varchar(255) column which won't work if we start to hand out JWT tokens for all apps. Also, we don't really want to be storing the whole JWT in our database either if we can avoid it.
Our idea is to have doorkeeper generate an opaque access token for all apps first, and store that in the db. Then before returning the opaque access token to the app, we check to see if the app has JWT tokens turned on and if so convert the opaque access token to a JWT access token using the opaque access token as the JWT's jti claim. We are thinking of utilizing the before_successful_strategy_response callback to convert to a JWT using the gem 'doorkeeper-jwt' if the app has JWT access tokens enabled.
Then, when we get a request which has an access token, check to see if the access token is a JWT access token and if so read the jti claim out of it and use that to load the access token from the DB. We don't have a good place to hook into this at the moment. Right now we are thinking of monkey patching Doorkeeper::Oauth::Token in the from_request method to check to see if the token is a JWT before returning it, and if so, return the JWTs jti instead.
Does that seem like a reasonable approach? Is there another way without monkey patching Doorkeeper::Oauth::Token?
More recent versions of doorkeeper allow you to configure the access token model class as seen here:
https://github.com/doorkeeper-gem/doorkeeper/blob/55488ccd9910e0c45ed4342617da8e026f4f55b5/lib/doorkeeper/oauth/token.rb#L17
So we can hook into the access token lookup there without resorting to monkey patching.
I have a doubt in the below condition?
(React and Rails separate application)
I'm saving JWT into the local Storage using the key "token" which sent from the rails server. I find the user in a particular request only through the JWT. What if the user changes the JWT in local storage. How could I handle this case?
If I check login is valid in each request, my server will die?
Any solution for this?
Thanks in Advance.
The JWT is already asymetrically encrypted when you get it, so the user will be unable to produce a legal JWT without access to the signing key. The client will still be able to decode the JWT and introspect it, however.
The best practice is to use an additional level of symmetric encryption on the server side, using an algorithm like AES. This means that the JWT is encrypted when given to the user, and only decrypted on the server side.
This gives a defense in depth from tampering attacks, as both the secret JWT key and the application's key are necessary to falsify the key. Symmetrically encrypting the JWT also protects information you have stored in it from the client.
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.
If I can perform authentication using oAuth2 using onelogin, can I also validate the same token using REST API's instead of accessing the the onelogin resources ?
I ask this question because for Google we can validate it using JWK keys, and other tokens ca be validated by the server keys. If that is not possible then at-least we should be having some REST API that could validate the token when passed. Does onelogin support any of these use-cases ?
Check out our OIDC support (https://developers.onelogin.com/openid-connect) as this basically allows for Authenticating users via JWT/JWK tokens
The Facebook OAuth 2.0 implementation allows you to convert a client side short lived access token into a long lived token using the FB_Exchange_Token grant_type i.e.
https://graph.facebook.com/oauth/access_token?client_id={YOUR_CLIENT_ID}&client_secret={YOUR_CLIENT_SECRET}&grant_type=fb_exchange_token&fb_exchange_token={SHORT_LIVED_ACCESS_TOKEN}
My question is does Google's version of OAuth 2.0 have a similar mechanism allowing me to get the short lived token via the client side flow, pass this token off to server and have the server convert that token so we can store the refresh token?
No, Google doesn't have that functionality. You'll need to use the server-side flow.
Can you give more info on the use case (in comments below?)