By signing, I mean the cookie itself, with a secret (cookie-parser allows for this).
Or is this pointless, because the JWT is already signed on its own?
Related
I am building a Django Rest Framework API which is using JWT authentication. I had created access tokens and refresh tokens and sent them to users.
I also have a refresh token endpoint that will take old refresh token and generate new pair of tokens and send to user.
I have doubt in its behavior related part. Currently what I can see that whenever I create new pair of access and refresh token using previous refresh token, the old access token is also working and new one is also working.
However once when I was using OAuth2.0 (in different case), I observed that in that case the old access token won't work if we had created new refreshed tokens.
But in case of my implementation of JWT in DRF this thing won't happens. I am not storing token in database.
So I want to know that is this any implementation specific problem or is it the property of JWT only, and if it is property then please share some details over it with me.
Thanks.
According to JWT introduction:
JSON Web Token (JWT) is an open standard (RFC 7519) that defines a compact and self-contained way for securely transmitting information between parties as a JSON object. This information can be verified and trusted because it is digitally signed. JWTs can be signed using a secret (with the HMAC algorithm) or a public/private key pair using RSA or ECDSA.
One of the value, that you can encode is 'exp' which states for expiration date. That's why your old tokens do not expire, cause they expiration date is still valid, and any other claims didn't change. Idea behind the 'refresh' token, is to provide new tokens with bigger exp value. Saying other way, you should not expect that the authorization will fail now, as the old token is still correct one.
As well you store nothing in the database (about this I also suggest to read answer provided by #sdoxsee
I have a doubt regarding the jwt token validation done by the REST api and was not able to find a simple yes/no answer. Assume that everything is being transferred over HTTPS.
I have the following setup
React app
REST API
AWS Cognito that handles the user registration/login
When a user wants to login, then the React app would call the AWS Cognito api and validate the credentials. If valid, Cognito will send back a jwt token (that will contain the necessary meta data) that can be passed to the REST API. Now I see two options
the backend verifies that the jwt token was not altered using the rfc spec. If valid, the api extracts the necessary meta data and continues to process the request
The backend verifies the validity of the jwt token, but also calls the Cognito service to verify the metadata in the token.
I think that since everything is handled over HTTPS and the fact that its hard create a valid token then the first point is enough. There is no need to have an extra call over the wire. Am I wrong ?
Found the following question from softwareengineering.stackexchange.com which pretty much answers my question. Link
The local validation of the JWT token is enough when the token was created with asymmetric encryption.
I'm sorry for what appears to be somewhat of a dumb question, but I'm playing around in AWS' Web Identity Federation playground and am not clear what type of access (authorization) token I am receiving when I first log in and the provider redirects to the callback URL. I first log in with my Amazon.com account, and Amazon supplies me with an access token. I understand that I will trade this in for an STS token so I can assume a specific role defined for me, but I wanted to inspect the token using the jwt.io site:
This all makes sense to me, but when I paste it into the jwt.io form to see its plaintext contents, I get an Invalid Signature error. If this is not a JWT, where is the information for access scopes (like profile and expiration windows (like 3600) stored then?
I'm guessing this means that the access token is not a JWT token, but rather only a simple string combination that has no real-world meaning and
basically says "Check this token is valid and then grant whoever gave you this token the permissions associated with it"? Is this always true for every web identity provider (Amazon, Google, Facebook, etc.)? Does the fact that token_type=bearer in the query string of the redirect URL mean that it cannot be a JWT?
If jwt.io says Invalid Signature, it’s not necessarily because the token is not valid, it is probably because you have not provided jwt.io with a valid signing key. In the signature box on the right, paste the signing key.
I am developing a restful web service and it needs securing. I am doing this using a token system where the client passes a token unique to them via the request header. The service has to be called via HTTPS.
I have seen a few articles which encrypt the token but is there any real benefit to doing this as the token would naturally be encrypted by HTTPS anyway....?
After re-reading the above I realise that it is not entirely clear what I meant...
The articles I have seen give the client a pre-encrypted Token which was encrypted with a public key. They then decrypt this token on receipt of the request and check it against the stored unencrypted token. To me it seems that this has no benefit over simply giving the client an unencrypted token and saving on the whole decryption overhead....
I think it's a broad question and the answer will depend on your requirements. But, in most of cases, you won't need cryptography in your identity tokens.
Identity tokens (used to perform authentication) can be opaque (tokens that reveal no details other than the value itself, like a random string) or can be self-contained (like JSON Web Tokens).
For more details, see below:
Random string
A token can be issued by generating a random string and persisting it to a database with an expiration date and with a user identifier associated to it.
JSON Web Tokens (JWT)
Defined by the RFC 7519, it's a standard method for representing claims securely between two parties. JWT is a self-contained token and enables you to store a user identifier, an expiration date and whatever you want (but don't store passwords) in a payload, which is a JSON encoded as Base64. The payload can be decoded and read by the client.
With JWT, you can perform stateless authentication, that is, you won't need to persist JWT tokens if you don't need to track them. Just check the integrity of the token by verifying its signature on the server side.
Although, by persisting the tokens, you will have the possibility of invalidating and revoking the access of them. To keep the track of JWT tokens, instead of persisting the whole token, you could persist the token identifier (the jti claim) and some metadata (the user you issued the token for, the expiration date, etc) if you need. To find some great resources to work with JWT, have a look at http://jwt.io.
For tokens with cryptography, have a look at JSON Web Encryption (JWE), defined in the RFC 7516. Use JWE when you need confidentiality, so the client will need a key to decrypt the content of the token.
The Twitter OAuth 1.0a flow requires authenticated request token to be exchanged with access token at consumer or client side after user has authenticated.
The problem that I'm facing is that generating access token needs authenticated request token, request token secret and verifier but the response from the oauth/authentication api doesn't have request token secret. So how do I temporarily save request token secret from oauth/request_token api call so that I can use it in oauth/access_token api call.
I found some solutions from my explorations like Running a Cache server (Memcached, Redis) or using django session feature. But they all seem to be overkill for this task.
I hope to find a simpler solution.
I'm sure you long ago figured this out, but just for future goolers: I decided to a go a more low tech route and create an OAuth token class which includes fields for the fetched and access token. Basically I take the fetched token, store it, then recall it when accessing (as it's in a different view) and then save the access token. Once (if) that's successful than I delete the fetched token.
There's likely a more glamorous way to do this, but if you're clever with your naming convention you can easily keep them straight (i.e. add a CharField for provider and just save the fetched token as twitter_fetched, and the access token as just twitter).
This has the added benefit of allowing you to create an OAuth1 or OAuth1Session from the stored access token.