I am using DjangoRest Framework simple-jwt package found at https://github.com/davesque/django-rest-framework-simplejwt.
this provides two api endpoints to get access token and refresh token. Currently I store the access token in localStorage in browser. Is this the best place to store it, or would sessionStorage be better?
When I need a new access token because the current access token expired, should I pass the refresh token (stored in localStorage) in a POST request? Is this the best implementation? It seems insecure to have this crucial refresh token string stored in the browser.
That works and yes, you would pass the refresh token. Since you're using it for a web app I suggest you make your access token and refresh tokens expire rather quickly this way it's always generating a new one.
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
How to expire django rest framework JWT token manually ? Because it does not store the token in the database. Is there any correct way to expire the token ?
I am thinking to continue with middleware where token will be stored per user. At every login request we will update the token in the db for a user. At every request, we will fetch the token from request and comapre with the stored token and if doesnt match then we'll return the forbidden. I dont know its a correct way or not !!
You can't expire JWT token, the token is self contained and can only be expired after amount of time that's stored in its payload.
What you can do is to use both refresh and access token, and set little amount of time for access token. With that being said you FE should update access token when it's expired. You should store your refresh token in database, and when you need to delete access token, you can stop user from updating it using refresh token.
EDIT:
If you want to store token in database, you probably don't wanna use JWT and stateless authorization at all. Instead stick with session based authorization. When you want to expire token - you can just delete session from DB.
UPDATE 2:
What people usually do in this situation is having a fast-access DB (like redis) that has very few items. Instead of storing jwt token in the database we create a table that contains blocked tokens (I assume the amount of deleted tokens would be much less than amount of alive ones). BUT, now you sacrifice stateless authorization in favor of checking if a token is in the database every time you authorize a user.
I'm using the php-jwt package for my Restful API to authneticate users.
I am successfully authenticating Users and returning a token. However it seems that there is not a standard method to issue a refresh token. Although I understand the principle and the flow I'm not sure if there is a standard for the issuing of the refresh token?
If I unerstand correctly the flow is as follows:
App requests access
API checks for a valid User and issues a token which is to include a refresh token
refresh token is sent along with a request to renew, it is verified and if valid another token is issued?
But my question is how to issue the initial refesh token. Is this simply encoded in the token itself along with other data that I return such as username and email for example?
Thanks in advance. A.
I'm currently doing a bit of research of my own on JWTs. I believe you can give the client 2 tokens after auth: an access token and a refresh token. The refresh token can also be a JWT itself. What goes in it is up to you but I think what's important is that it is a valid/not expired token when used. If you can successfully validate it, then you can issue a new access 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.
When we do oauth2 on google api, we get an access token and a refresh token. Suppose I'm writing a service and I want to periodically poll for changes I can just use refresh token to get fresh access tokens every time the current access token gets invalidated. This is called offline access.
Is there any way to do the same in facebook? Is there an offline access version similar to that of google api.
Thanks.
For offline access, you need to exchange your short-lived access token for a new access token, before it expires. Facebook has a single type of access token (no refresh tokens). A about-to-expire access token should fetch you a new access token.
To manually extend the tokens using a Graph API endpoint ::
GET /oauth/access_token?
grant_type=fb_exchange_token&
client_id={app-id}&
client_secret={app-secret}&
fb_exchange_token={short-lived-token}
Quoting FB's documentation from here ::
Apps are unable to exchange an expired short-lived token for a
long-lived token. The flow above only works with short-lived tokens
that are still valid. Once they expire, your app must send the user
through the login flow again.
Do read the Expiration and Extending Tokens portion of the documentation link that I have mentioned for further clarification.
You can check the validity of your token from here , according to my token it expires never