i have identity server that provide access token to the login user and api(multiple) that have bearer token authentication but in case of authorization I need to know how to authorize user by using user permissions and not only client scopes. the issue here is to load those permisions from authorization server independent from identity server because user might have to many permissions that can not be added into access token through IProfileService. I tried to add those permission into access token but it caused the token to be too large and request header has limitation of 8kb and 16kb in IIS server.
I was thinking of using IDistributedCache for sharing user permissions but I dont think it is a better solution.
Related
i'm having a diffculty with Access Token.
And i'm new in web dev, taking a role in front-end.
So far, my web site is connected with server for log in API, and i can verify user infomation after logged in at console.
However, i'm wondering the way to get access to Access Token which is issued from the server.
So, the logic is as follows,
When i sucess logged in with correct user information, AccessToken and Refresh Tokens are issued.
I needed a code to access to Access Token, so if i have, i can access to prevented pages (such as, MyPage)
The Access Token has 30min of expires, so after logged in 30min,the issued Access Token must be expired and lost its access rigth to private pages.
Summary !
I'm wondering the way to code the AccessToken in Client side to server side after logged in. Found some of informations that saying include Access Token in headers request in Client side.
How can i code whether the Access Token is expired after 30 min and reqesting again to issue the access-token when i access to private pages with access-token expired state.
Then, if server can find there is a refresh-token in Client side, then issues access token very easily.
Wondering should i put all of the pages that check wether AccessToken is alive?
Normally, it handle by token middle-ware between front-end to IdP(ID provider) server.
It automatically refresh the access token by refresh-token.
The middle-ware's roles
refresh token together with the access token when the user login is processed.
access token and refresh token are re-issued when the refresh is executed
saved the access token and refresh token into local storage (usually called cookies)
If an access token is expired when you execute an API, it will be able to execute the API with a new access token if a refresh token is valid
If an refresh token is expired when you execute an API, it will be able to execute the API with a new access token if a refresh token is expired after got new refresh token.
Popular IdP is Keycloak provides middle-ware for multiple languages.
Java, Javascript, Python, Spring Boot, Angular, React
sorry, I missed your question
I'm wondering the way to code the AccessToken in Client side to server side after logged in. Found some of informations that saying include Access Token in headers request in Client side.
The front-end access an access token and decode it for getting user's information, role and expires time
How can i code whether the Access Token is expired after 30 min and reqesting again to issue the access-token when i access to private pages with access-token expired state.
middle-ware takes care the life time of access token
Then, if server can find there is a refresh-token in Client side, then issues access token very easily.
Yes,
Wondering should i put all of the pages that check wether AccessToken is alive?
It stored in local storage in single place and use it from mutiple pages
There are a few things I might not agree with in #BenchVue answer:
Client should retrieve user data from ID-tokens only. Access-tokens audience are resource-server(s), can be opaque and should be used only as authorisation headers.
Authorization-server (middle-ware in the answer) defines tokens expiries. It does not refresh it auto-magically. Clients must handle tokens refreshing, which can be done pro-actively as OAuth2 token responses contain expiry in adition to the token itself (even for opaque token).
Do not code a gripped weel. Pick a lib. You're very very likely to make security breaches otherwize. Plus you'll waste a lot of time implementing stuff like:
redirection to authorization-server for login / logout when user tries to access a protected route
silent access-token refreshing (just before it expires) using refresh-token
JWT adding as Bearer Authorization header to secured resource-server
etc.
We have used JWT authentication scheme and resource owner password grant type with identity server. Backend is .Net core based micro services which is providing access token to angular based front end website.
As jwt token is not revocable and business requirement is to have longer access token lifetime, it seems only option is to have track of blacklisted tokens in database or cache.
Is there any way to modify the access token on backend and make it expire immediately when user triggers log out from frontend?
JWT cannot be revoked, it is by design as it is self-contained. Revocable alternative is Reference token which is not self-contained and thus server needs to actively communicate with identity server.
The compromise and common approach is to set access token lifetime to lower value and increase refresh token lifetime. Refresh tokens are revocable - it is supported by identity server 4 as well. So it is all about trade-off between the frequency of communication with your Identity server and long access token lifetime.
The JWT tokens are stored in the browser, so you can delete the cookie of it.
But this option gives no security on the server side.
If you are worried about deleted/suspended accounts then yes, you have either to create a blacklist but you have to compare them for each request.
The other option is to reduce the expire times and rotate them. there is a post with more details here Invalidating JSON Web Tokens
I have got a React application and also a backend API server which are hosted separately. I use cognito for authentication. When the user signs in, I receive 3 tokens - id token, access token and refresh token.
I have read that id token is used for authentication while access token is used for authorisation.
I am a bit confused which token (id token or access token) should I use when making API requests to the API server.
You should use the access token. It is for authorization. When you check if a user has rights to access resource it is authorization.
Authentication checks the user identity, so it gives you answer to the question - Is this really that user?
These terms should sink in, so read it here once more:
Authentication versus Authorization
I'm trying to figure out if I'm using the correct API calls to revoke my apps access to a users Twitter account (so when a user attempts to log in with Twitter again they have to grant my app access instead of not asking to log in)
On my app locally I have a server running where a user has the capability to grant my app access to their Twitter. I am successful at obtaining an access token using
https://api.twitter.com/oauth/request_token
but when it comes to revoking that same access token I've attempted to use
https://api.twitter.com/oauth2/invalidate_token
described here: https://developer.twitter.com/en/docs/basics/authentication/api-reference/invalidate_token
but it seems to use oauth1 to obtain the access_token and oauth2 to invalidate it which seems odd. I'm able to POST but the error I receive is 403 "Unable to verify your credentials"
In the description of invalidate_token call, it mentions invalidating an "OAuth 2 Bearer Token" but obtaining the token I obtained an "OAuth Request Token".
Can one authenticate with OAuth2 to invalidate a token obtained with OAuth1? Or am I missing something?
The server is running PHP and calls are with curl.
You cannot programmatically revoke OAuth1 tokens using the Twitter API, unless you are using Bearer Tokens. In your case, you are not using Bearer tokens, but standard OAuth1 request and access tokens.
Rather than revoking access, you can direct users to the GET oauth/authorize endpoint which requires the user to re-approve the application:
https://developer.twitter.com/en/docs/basics/authentication/api-reference/authorize
However, please think carefully about why you are doing this -- typically, a user grants your application permissions once and then revokes it themselves through their Twitter settings, as described here:
https://help.twitter.com/en/managing-your-account/connect-or-revoke-access-to-third-party-apps
I'm new to oAUth2 and I'm trying to get a few things straight.
I understand the basic principles involved with oAuth2 but I am not sure how to implement it in my situation.
I am writing an app that acts on behalf of the user to automate a manual process and perform some tasks(update/request status...etc). The API we are connecting to uses oAuth2 to grant our application permission. We plan on having the user grant our application permission when they create a new account with us.
I understand that the user will request an authentication code that is provided to our application. Then our application will use the authentication code to generate an access token.
We would like to do this only once. Then act as the user to send and receive notifications without having to have the user to log into the service with their credentials.
I am not sure how to implement this without having to store the user credentials to get an auth code since the auth code and auth tokens expire. I'm guessing that this is a common scenario.
What would I need to do to get what I want accomplished?
You can get a new AccessToken using a RefreshToken, if this is provided by the Authorization Server.
If it's not provided I would contact the Api provider, you should never store a users credentials. In fact if the OAuth protocol is well implemented as a client you should never be able to even get the client credentials. When the user has to login you should redirect the user to the Authorization Server, there the user should login and then the authorization token should be redirected to your application by the Authorization Server.
See also this explanation on Refresh Tokens from the OAuth 2.0 spec:
Refresh tokens are credentials used to obtain access tokens. Refresh
tokens are issued to the client by the authorization server and are
used to obtain a new access token when the current access token
becomes invalid or expires, or to obtain additional access tokens
with identical or narrower scope (access tokens may have a shorter
lifetime and fewer permissions than authorized by the resource
owner). Issuing a refresh token is optional at the discretion of the
authorization server. If the authorization server issues a refresh
token, it is included when issuing an access token
Note
If you request a new AccessToken using your RefreshToken and the response includes a new RefreshToken you should overwrite your currently saved RefreshToken. With other words, you should always use the latest RefresthToken you received.