After authenticating with a provider, an application will often receive both an ID token and an access token on behalf of the user. Now it seems there are two ways to assert who the user is.
Verify the ID token and then read the ID token.
Pass the access token to the userinfo endpoint and read the JSON response.
Both seem like acceptable avenues, but are there certain scenarios in which one or the other should be used?
If you have both tokens and the ID token contains all info you need, you can use either way. Below are few differences that came to my mind:
Verifying and reading an ID token can be done without accessing its OAuth2 server (if you have its certificate already downloaded locally), which makes it faster and there are fewer possible errors to deal with - no network requests.
If the user info was changing often, an ID token could contain obsolete data, but it's hardly ever a case.
Access tokens can be revoked (ID tokens cannot), so if you need it, they will do the job better.
Apart from the technical differences there's a semantic difference as well: the id_token and the info in the there represents and identifies an authenticated user. That user is "present" and logs in to the application.
The access_token and the information returned from the userinfo endpoint represents information about the user who issued the access token to the entity that presents it. That user doesn't need to be "present" or logged in (anymore).
An id_token is typically "one-time usage" and an access_token usually can be used for a short period of time.
Now in the case that both tokens are issued and received at the same time when a user logs in with OpenID Connect, the two overlap.
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 trying to implement OpenID Connect Implicit Flow. The frontend Single Page App passes the ID Token down to the backend server (using Authorization header) where I need to validate it.
The documentation requires me to check that I trust the audience of the token (aud & azp fields). I'm struggling to understand the significance of this validation step and what are the security implications of not doing so. Why should I distrust the token if I'm not the intended recipient?
My reasoning is that if I trust the issuer it doesn't matter who was the token issued for. I would expect the claims to be the same for any clientId (is this wrong?). Ideally when I pass the ID Token around my microservices all they should know is what issuers to trust (and use discovery protocol for figuring out the keys).
What is the attack vector if I skip this validation step?
The issuer could be issuing tokens to different applications and those applications could have different permissions. Not checking the audience would allow an attacker to use a token issued for application A at application B and may lead to permission elevation.
To your suggestion: the claims may indeed differ per Client.
Here's another reason: If you check that aud claim only contains your client, it prevents other apps' stolen tokens from being used on your app. If a user's token gets stolen from another app, nobody will be able to impersonate the user on your app because the aud claim will not be correct.
I'm answering this for posterity.
You should check the issuer and if your client_id is the only one in the audience if you are receiving tokens from an external OpenId Provider. One that could have more than your client.
Claims are not global to the OpenID Provider, they can be per-client. A user can have "Admin" role on app-A, gets a token there, then tries to send app-B (your application) the same token hoping that your are not checking to which client it was issued for (its audience).
I know there are already many posts about Oauth, Oauth2, JWT, etc.. I have read many and I more confused than ever so I am looking for some clarification. I will propose my view on the subject and I hope somebody can tell me if my implementation is secure enough or what I am doing wrong and how to improve it.
I am building an API Rest server for serving my resources to my users. Let's suppose it is a bank app where users can deposit, withdraw and transfer money.
I am using nodejs, hapijs, jsonwebtokens, and bcrypt for my server. I want to implement two token authentication flow (Oauth2).
This is the way I am doing it:
User logs in to the auth server by giving some credentials (username and password).
The server verifies the user's credentials, if they are valid, it will grant access to the user and return a refresh token and an access token.
These tokens are saved into the local storage of the browser or mobile device.
The access token:
is signed as a jsonwebtoken.
contains issued date, expiration date (5 min), user data (id, username).
The refresh token:
is signed as a jsonwebtoken and encrypted with bcrypt.
contains a unique identifier
may contain an expiration date
is saved in the database.
As long as the access token is valid, that means, it has not expired and contains valid user data, the resource server serves the user the requested resources.
When the access token is no longer valid, the auth server requests the client to provide a refresh token in order to issue a new access token
The server receives the refresh token from the user, decrypts it, compares it to the one in the database, checks if it has been revoked, and checks its unique identifier.
If the refresh token passes all tests, the server issues a new access token to the client.
If the refresh token fails one test, the server requests the user to re-authenticate.
Notes: I am trying to avoid the usage of cookies.
Questions:
If the user is able to steal an access token, I guess it can also steal the refresh token. So, how can I make the refresh token more secure?
Is my perspective of the Oauth2 flow correct?
What can I improve?
Am I missing something?
The reason OAuth2 is so confusion to many people is because it uses different authentication flows depending on what kind of client is used.
OAuth2 distinguishes two client type, confidential or public. Next to that, there are 2 grant flows that are redirection based (auth code and implicit) which are meant to be used with a browser or browser control.
The other two flows (resource owner password and client credentials) are meant to be used from non-browser apps (CLI, background services, trusted mobile clients).
I've described the different flows and when to use them in more detail in this answer here.
I am trying to determine the best way to enforce password expiration rules in my solution.
The server-side exposes a REST API for operations with a custom active Security Token Service (of sorts). Client applications pass user credentials to a REST endpoint where the user is authenticated on the server. The response includes a custom security token representing the user which is then passed to other API methods so the call can be authorized. The server is stateless and does not maintain any reference to the identity or claims information (i.e. session-less).
We have password expiration rules that are enforced by the server. So, when authenticating a user, it is possible that their password has expired. I need to communicate this to the client so they can do whatever is needed to have the user change their password. (There is another REST endpoint for changing the password on the server.)
Questions
It seems to me that authenticating a user with an expired password should fail. However, I need to know the identity of the user changing the password when making the second API call, so should I go ahead and return a token even when the password has expired?
How should I inform the client that a password change is required? I thought about including this as a claim in the token, but that would require me to reissue a new token after the password has been changed or modify the original token which isn't allowed. My other thought was a custom HTTP Status Code that I would correspond to meaning Password Change Required.
The answer to this question probably depends on the previous two, but I don't want to authorize a user that has an expired password if the token is passed to any other APIs (besides changing the password). What's the best way to handle this?
So, what I ended up doing (certainly not the be-all-end-all solution) is having my Authenticate endpoint return an AuthenticationResultCode enumerated value in the response in lieu of a simple pass/fail boolean. Possible values for the enumeration include:
ValidCredentials - the user was authenticated and the AuthenticationToken is included in the response.
InvalidCredentials - the user was not authenticated
CredentialsExpired - the user was authenticated but their password has expired. I have yet to determine if the AuthToken will be included with this result.
NoCredentials - no credentials were provided to the request
Now the client has more information about the result than a pass/fail value (which I really never checked anyway) and I can take the appropriate action in response such as automatically displaying the ChangePasswordDialog when CredentialsExpired is received.
Like I said, still working out whether or not I should still send the token when the credentials are expired because I don't want to be able to authorize a user if their credentials are expired but they've already been authenticated once and I don't think it makes sense to re-authenticate after changing the password (after all, I have to be authenticated so I can change the password in the first place). Maybe just a simple IsLocked or IsExpired property on the client will suffice...