*I have simple question related to oauth token ,so my requirement is that user can have multiple scopes say A and B and he has generated token for it but later on he needs scope A and B both and his previous token is valid, So in that case
Should we update the scope for the existing token ?
Should we generate new token for new scope ?
Or should Generate multiple token for a single user ?
If you want to update the scope of the existing token and if your authorization server provides a mechanism for it, just do it. As a matter of fact, a certain authorization server implementation provides Web APIs to update scopes of existing access tokens (/auth/token/update API, /auth/client/authorization/update API).
Whether access tokens are modifiable or not depends on each authorization server implementation. For example, if the type of access token implementation is "self-contained" (e.g. like JWT), access tokens are not modifiable. On the other hand, if the type is "random string" (in this case, actual data are stored in the DB behind the authorization server), access tokens may be modifiable. See "7.1. Access Token Representation" in "Full-Scratch Implementor of OAuth and OpenID Connect Talks About Findings" for details.
Some authorization server implementations issue multiple access tokens for one combination of a user and a client application, and other implementations issue only one access token for the combination. A certain authorization server implementation provides a configuration flag to enable you to select either of the behaviors like below. See also this answer.
Which approach you should take depends on your use case. Look for an authorization server implementation which suits your use case best.
OAuth2 access token is no modifiable, so you should get a new access token with a different set of scopes. Access tokens are generated for an application, not a user, but yes, there can be multiple access tokens authorized by a single user - the user authorizes the application to perform some operations (scopes) on his behalf.
Related
I read a lot about OAuth 2.0 and OpenId Connect and in theory I understand both concepts now.
But if I go into practice, some things are still confusing for me and I hope you can enlighten me in some way...
First thing is, that in all code samples how to secure a .net core API in an AAD-environment I find lines like this in the configure-section:
app.UseAuthentication()
and lines like this in the ConfigureServices section:
services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme)
.AddJwtBearer(options =>
{
options.Authority = "https://login.microsoftonline.com/xxxxxxxx";
options.Audience = "xxxx-xxx-xxx-xxx-xxxx";
});
However, to access my API I am not using an ID token, but an access token what is Authorization, not "Authentication" like in the code samples.
This works - but I do not understand it 100%.
So my first question is:
Is the access token also "authenticating" in some way?
The second thing:
I read that access tokens have no standardized format. They can be JWT or not, can have an audience or not etc. For this reason you could even put user information in the token like microsoft does. The access tokens contain claims like a "family name" or "given name" etc.
Id tokens in contrast have a standardized format to ensure that authentication is done in the same way by everyone.
If people are accessing my apis with an access token, I can read their name or e-mail address with "user.identity.name" for example. This value I can use to store the information who edited something or who inserted something.
So I am fetching information about the user with access tokens!
So my second question is:
Am I doing the right thing here? Or should this be done in another way.
and:
Should access tokens ever contain information about the user?
Is the access token also "authenticating" in some way?
Yes.
Your API is validating the access token when it receives it.
This is the authentication part, when your API verifies that the token signature is valid, came from the Azure AD tenant that you trust, that it is meant for your API and that it has not expired.
The authorization is when you check what permissions the token contains.
Your API can define different permissions that are given to client applications, allowing them different levels of access.
A valid token can pass authentication, but it might not pass authorization if it lacks the necessary permissions.
Am I doing the right thing here? Or should this be done in another way.
Fundamentally your are doing the correct thing.
The token tells you who the user is that is using the client application, and if you need to know who it was who did something, that's the info you use.
However, if you really want to connect an action to a user, I suggest you use their object identifier / object id / oid instead of their name / username as those can change.
Unless you just want their display name.
Should access tokens ever contain information about the user?
In the context of Azure AD, an access token will always contain info about the user if a client application is accessing an API on behalf of a user.
This includes authentication flows like authorization code, device code, implicit, and on-behalf-of.
They all use delegated permissions aka scopes to call APIs on behalf of the user.
Thus the token contains info about the calling app and the user.
If an app acquires an access token using the client credentials flow where a user is not involved, there will be no user info in the token.
In this case, application permissions are used instead of delegated permissions in Azure AD.
An application acts as itself, not on behalf of any user.
If your API supports both of these scenarios, sometimes the tokens contain user info and sometimes not.
The part about token formats is basically correct from a specification standpoint.
OAuth doesn't define a strict format for access tokens, while OpenID Connect does define one for ID tokens.
Using an access token to call your API is definitely correct.
The ID token is only meant for the app that initiated the user authentication, not for any APIs that it calls.
That's what access tokens are for.
if you check here: https://learn.microsoft.com/en-us/azure/active-directory/develop/access-tokens
in the newer access tokens, by default it follows the standard of not having any personal information about the user. which is what the standards suggest, Access tokens should not contain much or any information About the user. rather just information for authorization (things that user can access).
However you can always add the optional claims (and azure lets you do it) for personal info, but best practice suggests you shouldn't.
in terms of the addauthentication: Authentication is basically proving who you say you are. addauthentication(), basically calls microsoft azure ad to perform this task, saying hey aad please ask this person who he is, azure then checks and says ya this is a real person, but i won't tell you anything about him other than an id, and they have access to your api/application. So from your snippit, it's fine.
at this point, your serverside shouldn't have any personal information about the user, just that they have access and what scopes/roles. If it wants info about the user, it should then take that authorization (access token) and request it from whatever endpoint that token has access to (graph)
here's a great read about it: https://auth0.com/blog/why-should-use-accesstokens-to-secure-an-api/
Hopefully this helped clarify somewhat, and not add more confusion to the issue.
On most of the JWT (JSON Web Token) tutorial (e.g: this and this) are saying, once validated you can use the incoming token to get client information without validating it from the DB.
My question is, how invalid user situation is maintained then? What I mean is, lets say a client just got a JWT token which expires in one week. But for very specific reason lets say we decided to invalidate the user, and don't want the user to access our API. But still that user has a token which is valid and user can access the API.
Of course if we take a round trip to DB for each request then we can validate if the account is valid or invalid. My question is, what is the best way to take care this kind of situation for long lived tokens.
Thanks in advance.
It's difficult to revoke JWT-based access tokens if not impossible.
How should an access token be represented? There are two major ways.
As a meaningless random string. Information associated with an access token is stored in a database table behind an authorization server.
As a self-contained string which is a result of encoding access token information by base64url or something similar.
A choice between these ways will lead to consequent differences as described in the following table.
See "7. Access Token" in "Full-Scratch Implementor of OAuth and OpenID Connect Talks About Findings" for pros and cons of the ways of access token representation.
If your access tokens are JWT-based, your system has to (1) remember revoked access tokens until they expire. Another compromise is to (2) make lifetime of access tokens short enough and give up revoking them.
Personally, after consideration, I didn't select JWT as access token representation when I implemented an authorization server (Authlete) because it is difficult/impossible to revoke and update JWT-based access tokens once they are issued.
RFC 7009 specifies OAuth 2.0 Token Revocation. Basically you have an endpoint where you can revoke the access_tokens.
It's not clear which OAuth flow you are using from your question, or whether you are referring to OpenID Connect rather than Oauth.
Consider using refresh tokens and have a much shorter expiration on your access token - e.g. 30 mins.
In this scenario, the user (resource owner) doesn't have to keep authenticating, and your API (Resource Server) doesn't have to check the user is still valid on every single request.
Once the access token expires, your client (application calling your API) should contact your DB (Authorisation Server) and exchange its refresh token for a new access token - and usually a new refresh token - providing the user is still a valid user on your DB and the user has not revoked access for the client application to his/her data on the API.
You could also use token revocation as suggested in another answer if your Authorization Server allows it but I would try refresh tokens and short-lived access tokens as it's much easier to implement and doesn't pollute your API with user authentication/authorisation concerns - this job is best done by an Auth Server.
That's the main problem when you are using JWT. So basically best approach in this case is creating blacklist on your gateway. It's not best solution for security point of view but this is only good solution if you are using JWT.
I'm facing an issue about the scope of validity of my token :
I have two or more Applications A that use the same Authorization Server.
An Application A User can forge a legit token and extract it to use it with the application B and get access to application B.
My Application B has sensitive data and API so I don't want it to be accessed with a token forged by any other application.
Is there any mechanism that limits the validity of a token .
Best regards,
A "real" token would be bound in time and scope but it would typically include an "audience" as well that would tell the recipient a.k.a. the Resource Server whether the token was really issued for it (or someone else). So the mechanism to protect against replay of tokens to another service is generically called "token audience".
OAuth 2.0 itself doesn't define the contents of the token, but if you're using a JWT token the audience would be recorded in the "aud" claim.
On top of that you could use the scope mechanism to define scopes that are only valid/accepted in the context of a particular Resource Server.
I have created AuthorizationServer using OWIN/Katana OAuth 2.0 Authorization Server. It is configured to use JWT as the AccessTokenFormat. The SigningCredentials here are derived from Audience Secret that is unique to each Audience.
I want to build a Client that uses this AuthorizationServer to get a token for using an couple of API's I've built (resource / audience).
I see in OAuth there is no concept of Audience (JWT concept), the only thing closest to this is a Scope. I can pass multiple scopes (audience) from Client but I don't understand how can I create a JWT in this case since multiple Audience are required to be able to validate the resulting token.
Any help or guidance appreciated.
You should be careful not to confuse two different concepts. The Audience claim indicates for who the access token is intended. You can only use it for services that have that value configured in the allowed audiences.
Scopes limit what the client can do with the token on the service. For example, one scope may allow the client to post to your feed, while another scope gives it access to your list of followers.
So you would typically need two different tokens to access two different APIs. That does not mean the user needs to authenticate twice though.
The authentication happens on the authorization server and while the user is still logged in to that server, he/she won't be prompted for credentials again. The user will be prompted for consent the first time they try to access a new API.
I am setting up OAUTH2 for my web application. Imagine the case, an entity ABC was authenticated and received an access token from my web application.
Is it necessary to ensure that the subsequent requests containing this access token from the entity ABC are indeed coming in from the entity ABC by having extra validation fields that only ABC is aware of.
OR, Should I grant access to anyone with this access token no matter who they are, believing that anyone who has this access token is indeed the entity ABC? As it's my responsibility to secure the access token transmission to the entity ABC
If you're using bearer scheme authentication, you grant access to anyone in possession of a valid access token. No additional info required.
See also:http://self-issued.info/docs/draft-ietf-oauth-v2-bearer.html
The current OAuth 2.0 specifications have standardized the usage of so-called "bearer" access tokens that grant access to any client that presents a valid access token as #user18044 describes.
There is work in progress on standardizing an OAuth 2.0 extension that would require the client to proof that it the rightful owner of the access token along with presenting it, the so-called Proof-of-Possession draft: https://datatracker.ietf.org/doc/html/draft-jones-oauth-proof-of-possession
That could be useful in environments that require a very high level of security, at the cost of a more complicated implementation. In most environments it would be enough to make sure that the access token is only ever passed over HTTPs to prevent it from leaking, so the current Bearer scheme would be sufficient.