I'm currently studying OAuth 2.0 and OpenID Connect and I have a doubt regarding the Authorization Server and Access Tokens. The spec defines the Authorization Server as:
The server issuing access tokens to the client after successfully authenticating the resource owner and obtaining authorization.
So as I understood, the client redirects the user to the Authorization Server, the user authenticates itself at the Authorization Server and the Authorization Server issues an access token to the client.
Now here comes a thing I couldn't understand until now. There are two possible ways to understand this and I'm trying to get the right one:
The Authorization Server issues the access token containing the user's claims. The access token with the user's claims is sent with each request to the resource server and the resource server is able to read those claims and based on then allow or deny access to resources.
The Authorization Server issues the access token already containing explicit instructions to allow or deny access to resources on the resource server. The resource server thus just reads this information to see if the user can do something or not.
The first option seems to be right way to understand the thing. In that case the Authorization Server will manage the user's claims and issues tokens containing just the claims (things like birthday, age, role and so on). This, in turns gives another responsibility to the resource server: deciding based on claims if a resource is available or not.
The second option is much more limited. Instead of just issuing claims the authorization server would need to issue authorization for each resource, and the token could get quite heavy and mananging this complexity seems to be hard.
So is my understanding correct? The Authorization is thus responsible for managing user claims and issuing token containing just the claims? On the other hand the resource server is responsible for allowing or not the access to resources based on claims?
An access token does NOT contain a user's claims, but an ID token does.
An authorization server is responsible for managing access tokens, but it does not necessarily have to manage users' claims. There should be a separate server that manages users' claims.
No. 2 sounds weird, because existence of an access token means "authorization has been granted."
OAuth 2.0 (RFC 6749) is a specification for authorization. OpenID Connect is a specification for authentication. Don't be confused.
Related
I have a custom OAuth 2.0 authentication server deployed alongside my secured API. I also have a single page application delivered as static content by an nginx deployment. I'm now confronted with the issue of how to authenticate users of this SPA without an active backend through which to proxy a password grant -- I obviously cannot embed the client secret in the SPA.
What solutions exist for such an issue?
I have discovered that the resource owner password credentials grant may be just what I'm looking for. By using this, I would be able to send username and password credentials directly from my trusted SPA using an established client ID. If I restrict this grant to only be valid for this particular client and validate the origin of the request, I can see this being a reasonable compromise.
My question then becomes, how do I create this client and the requisite associated user? Does that not imply that there is some special user account in my system with this associated privileged client? OAuth 2.0 seems to imply that clients must be associated with a user of some kind. Do I seed these special user and client objects when my application is deployed? Is that secure?
I think the implicit flow could be used just fine.
User is redirected from the SPA to the OAuth2 server
User authenticity is verified
User is redirected back to the SPA along with tokens
For the server-side API, you need to decide whether you want to use access tokens or ID tokens (OpenID Connect - OAuth2 extension).
If user's permissions for the API are stored at the OAuth2 server, the SPA may ask a user for some of the permission that will be included in the access token. This is a permission delegation and it can be handy if there are more application each requiring different permissions.
If the OAuth2 server doesn't hold the permissions and the API manages them itself, it's probably more suitable to use ID tokens, because they represent identity of the caller and can be verified without accessing the OAuth2 server on every access.
The API probably doesn't need to have its client_id, since it just accepts tokens - it doesn't request them - it checks that access tokens contain permissions for actions users invoke or validates ID tokens.
The SPA needs to have its client_id with registered redirect_uri-s. No client secret needed, since SPA-s cannot keep them safe. It has to be deployed using HTTPS to secure the transferred tokens.
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'd like to develop a native application (for a mobile phone) that uses OAuth 2.0 Authorization to access protected resources from a resource API. As defined in section 2.1 the type of my client is public.
Upon registration, the Authorization Server provides a client_id for public identification and a redirect_uri.
The client will make use of Authorization Code to receive it's Authorization Grant from the Authorization Server. This all seems secure (if implemented correctly) against any attacker in the middle.
In section 10.2 client impersonation is discussed. In my case, the resource owner grants the client authorization by providing it's credentials via the user agent to the Authorization Server. This section discusses that the Authorization Server:
SHOULD utilize other means to protect resource owners from such
potentially malicious clients. For example, the authorization server
can engage the resource owner to assist in identifying the client and
its origin.
My main concern is that it's easy to impersonate my client once the client_id and redirect_uri is retrieved.
Due to the nature of a public client, this can either be easily reverse engineered. Or in my case, the project will be open source, so this information can be retrieved from the web.
As far as I've understood from section 10.2, it's the resource owner's responsibility to check that the client is legitimate by comparing with what the Authorization Server SHOULD assist with.
In my experience with third party applications requesting an Authorization Grant from me, all I get is a page with some information about the client that actually should be requesting that grant. Based on pure logical sense, I can only judge if the client that's requesting the grant is actually the client that the Authorization Server is telling me who it should be.
So whenever we are dealing with PEBKAC (which I think occurs frequently), isn't it true that impersonators can easily access protected resources if the resource owner just grants them (which might identically look like my legitimate client) authorization?
TLDR - You want oauth access tokens to be issued only to valid clients - in this case devices that installed your app, yes?
First - Oauth2 has multiple workflows for issuing tokens. When YOU are running the Oauth2 service and its issuing tokens to devices running YOUR app, authorization code / redirect URL is not the relevant workflow. I suggest you read my answer here - https://stackoverflow.com/a/17670574/116524 .
Second - No luck here. Just run your services entirely on HTTPS. There is no real way to know whether the client registration request is coming from an app installed from the official app store. You can store bake some secret into the app, but it can be found via reverse engineering. The only possible way this could possibly happen can be some sort of authentication information being provided by the app store itself, which does not exist yet.
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.
When I first heard of OAuth was in ASP.NET Web API applications and I've used it as means of authorizing users to access resources on a RESTful API. By the time I felt I was using it right, but right now I think I got the idea wrong and this is the subject of this question.
At the time, I used OAuth in the following way: on the API there was a token endpoint to issue tokens. I created a login page in a SPA and posted the username and password to the token endpoint with a grant type password and the token that came back I started sending with each request.
When the request had the Authorization: Bearer [token] header with a token issued with some username on the login page I understood the request was being done "with the user logged in" and so I could authorize access to resources.
Studying OAuth deeper my conclusion is that my usage of OAuth was completely mistaken.
My understanding now is that OAuth is just for authorizing applications and not users. In that case when we make a request with the Authorization: Bearer [token] header we are saying identifiying to the resource server that the client making the request has been authorized to access the resource, but we are not saying anything about the user?
In that case, with OAuth we just can say what resources client applications can access but we have no information to decide whether the user is allowed or not to the resource? Because of that my initial usage is truly wrong right?
OAuth 2.0 can be used for authorizing a client (an application) to call an API. This authorization is done via an authorization grant.
The grant is given by the resource owner in the case of authorization code, implicit and resource owner password grant through authentication of the user with the authorization server and clicking accept on a consent screen.
The first two grant flows are interactive and require an agent that understands HTTP (redirection) responses.
Most authorization servers also support the client credentials grant. In this case, there's no user involved and a pre-registered client (application) uses its own client-id and secret to authenticate with the authorization server.
Which grant flow to use depends on the type of client you use and who owns the resource the client needs to access. I describe the differences in my answer here.