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.
Related
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 have an application that doesn't have user accounts so doesn't need a login. I'm currently authenticating using JWT via a /get-token endpoint in my api that's called as soon as the UI starts and returns a bearer token that's used for the calls for the calls moving forwards/
When that token expires, i'm a little confused at how to handle that. I was thinking using a refresh token but all the tutorials i've seen are passing the refresh token back to the UI, isn't that unsafe? I was always under the idea that the refresh token was internal and is only used on the server to refresh expired tokens.
What's the best way to handle this?
Refresh tokens carry the information necessary to get a new access token. In other words, whenever an access token is required to access a specific resource, a client may use a refresh token to get a new access token issued by the authentication server. Common use cases include getting new access tokens after old ones have expired, or getting access to a new resource for the first time. Refresh tokens can also expire but are rather long-lived. Refresh tokens are usually subject to strict storage requirements to ensure they are not leaked. They can also be blacklisted by the authorization server.
I'm building mobile and a web app. Both apps will be talking to a node server. I am using JWT for authentications.
Currently, I have the following code to generate an access token:
const token = jwt.sign({ user: body }, "top_secret");
I have some questions about access and refresh tokens:
How to create a refresh token?
What do refresh token look like?
Can I create a refresh token - similar to the way I'm creating an access token?
Is the refresh token only used to generate a new access token?
Can the refresh token be used as an access token?
How do you invalidate an access token
How do you invalidate a refresh token? Examples I've seen used databases to store refresh tokens. The refresh tokens are deleted when you want to invalidate an access token. If the refresh token would be stored in the database on the user model for access, correct? It seems like it should be encrypted in this case
When the user logs into my application, do I send both access token and refresh token? I read somewhere (can't remember where) that it's not good practice to send an access token and refresh token.
If its bad practice to send both access and refresh tokens, when do you send a refresh to the client? Should there be an endpoint where the clients request an access token?
What's a good expiry time for access tokens and refresh tokens?
Please note that in typical OAuth2 scenarios, the server issuing tokens (authorization server) and the API server consuming access tokens (resource server) are not the same. See also: Oauth2 roles.
To answer your questions:
How to create a refresh token?
You generate a string of sufficient entropy on the server and use it as a primary key to a database record in the authorization server. See refresh token syntax.
What do refresh token look like?
From https://www.rfc-editor.org/rfc/rfc6749#section-1.5,
A refresh token is a string representing the authorization granted to the client
by the resource owner.
The string is usually opaque to the client.
Can I create a refresh token - similar to the way I'm creating an access token?
You can, but refresh tokens are typically not structured tokens (like JWT) since they're consumed by the same server that issued them.
Is the refresh token only used to generate a new access token?
yes
Can the refresh token be used as an access token?
no
How do you invalidate an access token
Unless you're using introspection tokens, there's not a good way to invalidate them. Just keep their lifetime short.
How do you invalidate a refresh token? Examples I've seen used databases to store refresh tokens. The refresh tokens are deleted when you want to invalidate an access token. If the refresh token would be stored in the database on the user model for access, correct? It seems like it should be encrypted in this case
Delete if from the authorization server store. If the refresh token cannot be found on the server, it cannot be used to refresh an access token. A refresh token is typically just a primary key to a database record holding data about the client, user and expiration of the refresh token. While you don't want to leak your refresh token, it typically does require the client using them to present client credentials to use it.
When the user logs into my application, do I send both access token and refresh token? I read somewhere (can't remember where) that it's not good practice to send an access token and refresh token.
The user signs in at the authorization server. It returns an access token and refresh token (if your client is confidential) to the client. The client uses the access token alone to access your data on the resource server.
If its bad practice to send both access and refresh tokens, when do you send a refresh to the client? Should there be an endpoint where the clients request an access token?
Your client uses the refresh token in a call to the authorization server to get a new access token. So your client sends only the access token to the resource server and only the refresh token to the authorization server.
Whats a good expiry time for access tokens and refresh tokens?
That depends on your threat model. When your refresh token expires, the user is forced to authenticate again. Some products use refresh tokens that never expire, others use refresh tokens that are only valid for hours or days.
Azure AD is granting my application access tokens and a refresh token. When I use the refresh token to get a new access token, in return I get a new access token and a NEW refresh token.
Azure AD does not specify like Google Suite how many refresh tokens are allowed. But to the root of the problem, I don't want a refresh token being recreated and sent back, every time I use a refresh token. What is happening here? How do I stop this?
Returning of new refresh token is part of the OpenID Connect Protocol Specification which references the OAuth Authorization Framework section 5.1 for clarity.
Indeed the return of a refresh token is optional, but the implementation in Azure AD is so that it always returns a refresh token. I personally see no issue with it. Just throw away the last saved refresh token and keep the new one you got.
You cannot control this, it is done by design. It is also in complience with the OAuth 2.0 spec:
The authorization server authenticates the client and validates the refresh token, and if valid, issues a new access token (and,optionally, a new refresh token).
As for "floating out there", this only happens if you make it happen. If your app "forgets" the old refresh token then it is gone.