I'm following this tutorial for securing API (at 7:41)
The author suggested to:
Include a timestamp in the signed payload to protect against replays
JWT will help you with this
If you use HMAC, you will have to come up with your own convention.
Any example code on how to do token refresh with HMAC please?
I'm hitting an error where while I'm calling an API using HMAC, the token expired (expire every 2 minutes) and it throws an error back before I can request for a new token.
JWT has a refresh token will solve this issue (by having longer refresh interval e.g. 30 days). But will it actually solve the problem I'm having by switching from HMAC to JWT?
Related
I'd need some advice about an Api I have developped - and particularly on the Auth process.
The Auth process is made on a custom JWT and I'm happy with that. (I wanted to made my own JWT forgery and avoid using a library for that ; I'm not sure I did it well.
To get a JWT, my users need to POST their username+password on a payload. (yes, the payload is posted in clear on SSL.. I'll manage that later).
This JWT is forged (signed payload) by the server and last 5 minutes (short life)
Additionally to this Jwt the server returnd as well a refresh_token expiring after 24 hours.
The JWT is required for several endpoints using an header Authorization: Bearer ey.......
The users can also get a new JWT + refresh Token by POSTing the its refresh token.
The Api will send back to user a new JWT + a new refresh token ; respectively 5 min and 24 hours expiry.
I also allow users to generate ̀key+secret from a specific endpoint. Then, to get a new JWT (5min) + refresh Token (24h), it is possible for users to POST their key+secrets to an endpoint. Please note that ̀key+secret can be revoked/deleted before expiration and ̀key+secret` are valid for 24 hours after they are generated.
My question are :
Am I doing good setting on the token lifetime ? or is it too short/long ?
Would it be a good practice to have a longer lifetime for "key+secret" ; like having a 1 year expiration ? Or should I'd rather implement an endpoint to extend key+secrets validity by a week ?
Do you have any good practice website I should visit ?
Thanks a lot.
I'm trying to get my head around refresh tokens and how they work with JWT, so I can use it without auth0 API service.
Why refresh token format is different from JWT?
refresh tokens are just simple tokens store in the db?
How is the flow to use a refresh token to get a JWT token?
Thanks!
UPDATE
As #Florent Morselli suggested. The fundamental question of this post is wrong and confusing. Since JWT and refresh tokens are not really concepts that can be related. A better question can be:
What is the difference between a JWT Token and an opaque token?
What is the difference between a Access Token and a Refresh Token?
I'm not changing the question in the title, since somebody might be looking wrongly for the same thing and it will lead them to this post.
Token can be of two types:
Tokens by Reference
Tokens by Value
With the first type, the tokens are opaque strings (often random strings) that refer to a database index where the values associated to the tokens are stored.
With the second type, the tokens contain the values. To avoid alteration they are digitally signed or hashed. As they also may contain sensitive data, they can be encrypted.
JSON Web Token is a suite of specifications (mainly RFC7515 to RFC7520) that introduces a new format for the second type.
Why Refresh tokens issued by oauth0 are of the first type and not JWT (second type)?
The main benefit of the tokens by value is that they can be stateless i.e. you don't need any kind of database.
This is really helpful when tokens are sent several times to a server as they drastically reduce database calls and thus reduce the response time.
The drawback is that you cannot revoke them. Or if you add a revocation system, then you have to manage and call a database.
Therefore , tokens by value should have a very limited lifetime which is not compatible with refresh tokens.
Refresh token are used in Code flow or Hybrid flow as per OpenID Spec See Image below
Reference: https://openid.net/specs/openid-connect-core-1_0.html#CodeFlowSteps
Why refresh token format is different from JWT?
The format of Refresh token is also as per spec from OpenID
Reference: https://openid.net/specs/openid-connect-core-1_0.html#CodeFlowSteps
refresh tokens are just simple tokens store in the db?
Refresh tokens would be generated from your IDP(Identity Provider dynamically).
How is the flow to use a refresh token to get a JWT token?
Once you have the refresh token as shown in previous step, you can make a request to Token Endpoint with Refresh token to get Access Token
Access token
I'm learning making API Requests from a mobile app.
An API that I am using, returns an access_token, expires_in and refresh_token when making a login request.
I'm trying to understand the whole logic behind the access token idea, been looking all over the internet and cannot find a good example nor a good explanation.
As far as I am aware,
The best method for making API requests is:
1) Store the expires_in internally on the device
2) On every request first check if the token is expired
3) If so, then request a new one using the refresh token
4) Otherwise make the request
Is this right?
Your flow is basically correct.
If it is a JWT token, you can decode it. Inside you can find some properties, check here.
What you can do is use the iat property of the token, this contains the time when the token was issued (you can't rely on the received date from the WS) add the expiration time to that date, this will be the expiration date.
If you are using Alamofire is pretty easy, there are 2 protocols:
RequestAdapter
RequestRetrier
By using a combination of the two can you easily refresh your token, in the request adapter you can throw an error if the token is expired, in the retrier you can intercept this specific error and make a refresh token request.
It is explained here.
I am working on putting an application together that uses PayPal's REST APIs, starting with the invoicing API.
I am used to getting an Access Token and a Refresh Token with other implementations of OAuth 2.0 (ie, Google, MS, etc), but it seems PayPal has done away with Refresh Tokens in this instance.
Could I get some clarification? When the original access token expires, should I just request a new one? Or should I be receiving a refresh token as well and refreshing the Access Token using that?
Thanks!
Referenece: Access token validity and expiration
As the document mentioned, you should request a token and reuse it until it expires. Don't request a new token per session (and actually you will still get a same one before the one expires). It means that you should only request a new token when you meet a HTTP 401 response, and replace the old token with the new one.
I have application that continuously running in background. The app uses UCWA REST api. After authentication I get OAuth token and some expiration time. Authentication docs say "The lifetime of a token is eight (8) hours for authenticated users. The client application should monitor the expiration time and refresh the token as required".
So, when is it required to refresh token? What expiration time should I have in reserve when starting refreshing token? 1, 10 or 60 minutes? What are OAuth best practices?
The response from ticket service will provide the user with the OAuth token, type of token, and an expiration value. This value is measured in seconds which means you can divide out minutes (60) or hours (3600) to get a value that you can expect requests to start failing with 401 Unauthorized. Monitoring is most useful when the application is using anonymous meeting join because the token expiration is much shorter, ~1 hour, and it is the only authentication mechanism to directly offer renewing a token.
This leads to two potential approaches:
If using anonymous meeting join
Check expiration value found in authentication response and start a timer less than the expected value (maybe 1-3 min less)
When timer expires refresh the OAuth token
If not using anonymous meeting join
Send requests until a 401 occurs
Check response headers for WWW-Authenticate and send another authentication request to get new token
Re-issue request with new token
It is better to wait for the 401 to come before taking action to refresh the token in a non-anonymous meeting join scenario.