I am new to Oauth, can anyone explain what is the difference between Authorization code and client credentials grant type in Oauth
And also in which we need to use these two
I really appreciate the answers
The authorization code is obtained by using an authorization server as an intermediary between the
client and resource owner. Instead of requesting authorization directly from the resource owner, the
client directs the resource owner to an authorization server (via its user-agent), which in turn directs the
resource owner back to the client with the authorization code.
Before directing the resource owner back to the client with the authorization code, the authorization
server authenticates the resource owner and obtains authorization. Because the resource owner only
authenticates with the authorization server, the resource owner’s credentials are never shared with
the client.
The authorization code provides a few important security benefits, such as the ability to authenticate
the client, as well as the transmission of the access token directly to the client without passing it through
the resource owner’s user-agent and potentially exposing it to others, including the resource owner.
Client credentials are used as an authorization grant typically when the client is acting on its own behalf
(the client is also the resource owner) or is requesting access to protected resources based on an
authorization previously arranged with the authorization server.
Hope that helps.
Related
I am working on the ASP.NET MVC 5 web application. It has only one layer which contains views as well as business logic/operations. Business logic is logically separated from UI but it is not behind a separate web service/API layer.
Now when I use OIDC and OAuth2.0 for my application, there is no separate Resource Server, so to say. Because Client itself has all the Resources I want to have access to.
I am using Authorization Code Flow for authentication & authorization.
Questions:
Does access token have any role in this case? If yes, what?
How am I going to practically use the access token? Since the client itself is the resource server, there is nothing to which I need to send access token to.
I guess you get an ID token which contains all the information you need for authentication of a user. If not, you can use the access token to get the user info. If this is all the information you need, then the access token is not needed anymore. This happens, because OAuth2 is a permission delegation protocol, not an authentication protocol in a first place.
When you have the user info, you can implement between the browser and your ASP.NET backend in any way. You can take a look at the OAuth 2.0 for Browser-Based Apps RFC.
In this case you should use Client Credential flow instead of Authorization Code flow.
In Client Credential flow, your application would send your client id & client secret to Authorization Endpoint directly and asking for access token. Authorization Code is not needed in Client Credential flow. Details as below
An authorization code flow typically need your client redirect
resource owner to authorization endpoint and get a authorization
code from authorization endpoint, client than uses this code to get
access token, at the end of the day client uses access token to
access protected resource.
In Client Crendential flow. your client app is actually the owner of
your resource. So no need to asking for a authorization code. direct
uses its own client credential to get access token from
authorization endpoint and use that access token to access protected
resource(Resource server)
Please refer to this video, specifically from 20.00 to 25.00.
https://azure.microsoft.com/en-us/resources/videos/new-authentication-model-for-web-mobile-and-cloud-applications/
The work flow he describes is this:
Client app connects to authorization end point through the browser. User enters credentials, and authserization server authenticates the user and sends the auth code using a re-direct. Client app intercepts the browser activity and extracts the auth code. A new request is made to token end point together with this auth code, client id and few other information. In return, app gets access and refresh token.
What stops some one from stealing the auth token in the first step (say through browser history), and then contacting the token end point to get access and refresh tokens?
First off authorization code is only good for about 3 minutes normally. Second authorization code can only be used once. Third redirect uri must be a valid one that was registered for this client on the oauth server
The client initiates the flow by directing the resource owner's
user-agent to the authorization endpoint. The client includes
its client identifier, requested scope, local state, and a
redirection URI to which the authorization server will send the
user-agent back once access is granted (or denied).
The authorization server authenticates the resource owner (via
the user-agent) and establishes whether the resource owner
grants or denies the client's access request.
Assuming the resource owner grants access, the authorization
server redirects the user-agent back to the client using the
redirection URI provided earlier (in the request or during
client registration). The redirection URI includes an
authorization code and any local state provided by the client
earlier.
The client requests an access token from the authorization
server's token endpoint by including the authorization code
received in the previous step. When making the request, the
client authenticates with the authorization server. The client
includes the redirection URI used to obtain the authorization
code for verification.
The authorization server authenticates the client, validates the
authorization code, and ensures that the redirection URI
received matches the URI used to redirect the client in
step (C). If valid, the authorization server responds back with
an access token and, optionally, a refresh token.
#section-4.1
Oauth flow
Lets do this with some correct terminology.
Client = your application
authority= identity or oauth2 server (authority)
resource owner = user whos data you wish to access.
Resource owner loads client, client notices that resource owner is not authorized. Resource owner contacts authority identifying itself using a client id and possibly a client secret and sending a redirect uri, and requests scopes. (some of the things sent depend upon the setup of the auth server)
Authority notices this resource owner is not logged in prompts them to log in. Resource owner logs in and checks what scopes the client originally requested. Prompts resource owner to grant client access to said scopes.
Resource owner consents to access. Authority returns to the client an Authorization code.
Client says nice i have an authorization code and returns to the authority the authorization code and its client id and secret. This way the Authority knows that this is in fact the client that the resource owner authorized.
Authority then returns an access token back to the client that it can use for the next hour.
Access tokens are not then re-validated. So if someone stole this access token they would be able to use it until it expires.
According to the IETF's OAuth 2.0 document RFC 6749, it is implied that it is a good practice not to expose the token issued by the authorization server to the resource owner:
The authorization code provides a few important security benefits,
such as the ability to authenticate the client, as well as the
transmission of the access token directly to the client without
passing it through the resource owner's user-agent and potentially
exposing it to others, including the resource owner.
Do you know any reason for this?
It highlights that access tokens are credentials that must be kept confidential and available only to:
the authorization server that issued them
the resource server for which the credentials are valid
the client application application to which they were issued
Not even the resource owner needs access to these credentials; the most important part of the authorization code is of course reducing the risk of exposure to others, however, having an explicit note to mention the resource owner makes it clear that the target recipient of an access token is the client application.
RFC claims that (Figure 1):
(A) The client requests authorization from the resource owner. The
authorization request can be made directly to the resource owner
(as shown), or preferably indirectly via the authorization
server as an intermediary.
Does this mean that upon request from the owner of the resource authentication protocol is not used?
Or what does it mean?
This means that the client can request the resource onwer credentials in both ways:
Directly to the resource owner, asking for user and password to the resource owner and then sending them to the authorization server,
Or preferably via the authorization server, for example when you use your google or facebook account to authenticate in a web site.
Generally OAuth definition says that it is way where user gives an application access to his resources stored in other application (without exposing the actual username and password). But inside Owin, it is a way to implement token based authentication within an application. Although we can deploy the Authorisation application at different server. But crux remains the same. Could anybody shed some light. I am very confused.
Thanks in advance
If you take a look at the OAuth 2.0 spec you will find this:
The authorization process utilizes two authorization server
endpoints (HTTP resources):
o Authorization endpoint - used by the client to obtain
authorization from the resource owner via user-agent redirection.
o Token endpoint - used by the client to exchange an authorization
grant for an access token, typically with client authentication.
As well as one client endpoint:
o Redirection endpoint - used by the authorization server to
return
responses containing authorization credentials to the client via
the resource owner user-agent.
Not every authorization grant type utilizes both endpoints.
Extension grant types MAY define additional endpoints as needed.
So basically, you have 2 options:
1) Use the authorization endpoint where your end-user is redirected to a form that is handled by the authorization server
OR
2) Create your own form inside your app, get the end-user credentials and send that data to the authorization server, where it will be validated and return a token for you to use.