I have created an appian Connected System for DocuSign authentication with Authenticate Code Grant. I am able to authenticate & hit APIs successfully. But the issue is my token gets expired every 8 hours, then I have to go and authenticate from Connected System file again.
Please help me understand how can I refresh my token when its expired/about to expire.
I can explain how refresh tokens are used to generate a new access token.
However, this may not be possible with Appian, I am not sure about that, because I'm not sure about how Appian works.
First, you have to store the refresh_token you got when you used Auth Code Grant to get the original access_token that expired. That token can used to get another access_token later.
To get a new access token, use the refresh_token as you would an authorization code, but with a grant_type value of refresh_token and a refresh_token parameter that holds the contents of the refresh_token.
Read more in this Developer Center page
Related
From what I understand so far about access token is that in Code flow, Client could get access token with either authorization code or refresh token.
But.. can it get new access token with access token it holds before the token's expired?
I read RFC6749(1.1 ~ 1.4, 4.1, 4.2, 5 sections only for the sake of time) and I couldn't find such that
"access token must get issued by only explicit resource owner's grant or refresh token"
So I've been thinking..
How about issuing access token with access token.
What's wrong with this?
I'm almost noob to OAuth and learned it with only internet so I might totally misunderstand something D:
please enlighten me.. thanks!
You cant use an access token to get a new access token. Access tokens are self contained bearer tokens which grant you access to some data. (denoted by scope) For security reasons access tokens have a limited life time. Once it has expired you can not longer use it.
Consider if someone with a malicious intent got a hold of your access token. They can then use this to access the data, but only for a limited amount of time. Once the access token expired they would no longer be able to access that data.
refreshing access
The first step of the auth process gives you an authorization code, this is a one time code extremely short lived probably five minutes and can only be used once. When you exchange this you will get an access token and a refresh token if you requested offline access.
Refresh tokens can be used to get a new access token. You can use it to get access at a later date without requesting access of the user again. To get a new access token though you need to have the client and i and client secret that were used to create the access token in the first place, and in some cases you need to have access to the server that the redirect uri is residing. This way if the same a malicious person got access to their refresh token they cant use it to get a new access token unless they have your , client id, client secrete and server access.
You may find this interesting Understanding oauth2 with curl
TLDR
To be able to revoke access. Refresh token is used for that.
Here is my understanding. Access token are not retained by the auth server that issued them. They are very large in size and there may be a great number of them in a general case, one per scope or a set of scopes. Refresh tokens are short opaque strings and are retained by the auth server. They can be invalidated by the auth server to revoke authentication if a user's system has been found compromised. If an attacker obtained access/refresh token and used them from a different IP, for example. In this case the auth server will set a flag against the retained refresh token and will not refresh an access token without re-authentication.
Good evening, I ran into a problem that I need to make authorization more secure and without re-logging. I read on the Internet that you need to use two tokens (access and refresh), but how to properly do authorization with them. You can advise a resource where competent authorization with two tokens is made.
My Tech Stack:
MongoDB
ExpressJS
ReactJS
NodeJS
If you request authentication with offline_access scope, you'll geta refresh token in addition to an access token. Save this refresh token to the database and whenever you need to make another call on behalf of the user you can
Make the call using your existing access token. If you don't get a 401, then you're good.
If you did get a 401, your token is probably expired and then you can call the token end point on the authorization server with the refresh token and grant_type=refresh_token to get a new access token and try your call again.
Might make the most sense to always request a new access token using your refresh token before you make another call.
To my knowledge you only deal with access tokens for authorization. The refresh token is only there to refresh an expired access token. The refresh token is exchanged for a new access token - without needing to present authentication credentials again. The call also (typically) takes a fraction of the time than re-authenticating.
as soon as the user log-in, give it two tokens refresh and access, store the refresh token in the database, give access token a expire time (5-10 min approx or less depending on your requirement).
for each request user will use the access token and for each request backend should check for the expired access token.
if the access token is expired, user will get a new access token by sending the stored refresh token to the backend(using a dedicated endpoint), backend will than check whether the refresh token is present in the database or not, if yes a new access token with new expire time will be sent in the response.
the cycle will continue until the user logs-out, in that case the refresh token will be deleted from the database and after some time access token will also get expire.
I am using Keycloak to secure my react front-end and node.js back-end. These clients are protected using role based authorization.
My front-end application registered in Keycloak as a public client and back-end registered as bearer only client. When a user logging in to the front-end, i am taking the access token for that particular user and i am using that access token to call back-end api layer.
When user logout from the front-end i am clearing the front-end client session of that particular user from Keycloak by using keycloak object logout method. That is working fine and user is logging out and redirected to the Keycloak login page.
But the issue is i can still use the access token of that logged out user to call back-end api. The access token is still valid even though the user logged out.
I tried this end point to revoke the user access token. But didn't work
/auth/admin/realms//users/
Is there a way to revoke the access token of a particular user in Keycloak ?
I think you can only revoke sessions but not issued access tokens. So the only solution for this is to choose a very short access token life span in combination with silent refresh, so the usability is still good and the maximum access time after session revocation is equal or less than token life span.
EDIT: There is an official guide about how to handle compromised tokens. They do not mention how to revoke an individual access token, so there is no documented way to do so. However, you can revoke all issued access keys by the described "not_before" way.
It's possible at least on KC 17.0 via /protocol/openid-connect/revoke but since it's auth endpoint, you have to provide both the token and client_id, because the server must validate if the token belongs to that specific client that's calling.
This means that along with client_id, you may also need to send a client_secret or whatever other accepted of authenticating the client app to the server -- much like it was done earlier while obtaining the token on /protocol/openid-connect/token.
Also worth noting that the token must be passed as POST form param or GET query param of that name: token, and not as a bearer header/etc.
BTW. Refresh tokens can be revoked with the same /openid-connect/revoke endpoint in the same way as access tokens, while the older, easier to find /openid-connect/logout still only handles id tokens and refresh tokens (POST a client_id, client_secret etc, and also either refresh_token or id_token_hint to be killed) and still rejects any attempts with access token. At least on KC 17.0
BTW. I have no idea if /revoke can handle id tokens. I doubt it, but RFCs seem to allow that as custom extenstion. I have not tried with KeyCloak 17.0
You could call the following endpoint to revoke an access token using a post
{serverName}/auth/realms/{realmName}/protocol/openid-connect/revoke
I'm using Oauth2 to handle authentication in my system. While the authentication works, I'm worried about the security of my refresh token endpoint. The front-end calls this endpoint to get a new access token after it expires.
My question is how would you prevent someone from calling that endpoint and getting a new access token? Would you use the access token to authenticate yourself? At the moment I'm using these tokens to authenticate API calls on a separate service.
The endpoint currently supports csrf, but that's probably not enough.
Thank you!
The refresh token is used to get the new access token. That is where the authentication happens.
You can decrease the time that a refresh token is valid.
You can also choose if you want the refresh token to be renewed or not with each call to refresh the access token.
Unauthenticated clients cannot call the refresh token endpoint and get a new access token.
While using authorization grant flow for authenticating with Docusign, I am able to generate access token and refresh token.
Now I am using refresh token to get a new pair of access and refresh token. After new Access and refresh tokens are generated, I am able to make calls with older as well as newer access token. This means that new access token generation do not invalidate the older access token. This looks like a bug. Can Docusign Team confirm this. Is this the intended behaviour?
The access token should last until it expires.
The DocuSign system does not invalidate tokens when a new token is requested.