问题
I am trying to get my head out of the clouds with identity server.
I would like to implement the identity server project to let authenticate
- An ASP.NET MVC 5 application
- An ASP.NET Web API
- A windows service implementation
Int this blog post I have read some details about clients. The author simply state:
OAuth 2 provides several "grant types" for different use cases. The grant types defined are:
- Authorization Code for apps running on a web server
- Implicit for browser-based or mobile apps
- Password for logging in with a username and password
- Client credentials for application access
What are the differences between Authorization Code and Implicit? Do this means that implicit should be used for example by javascript code?
It is right to say that I need:
- the Password grant for ASP.NET MVC application
- Client credentials for Web API
- Authorization Code for the windows service?
Also another question, I would like to implement authorization in my web api based either on Bearer Token as well as a simple apiKey. Can both types cohesist? How do I implement apiKey by using Identity server?
thanks a lot and excuse me if these are stupid questions.
回答1:
I tried my best to keep this answer short (But I was forced to add lot of context to make sense of the answer)
Confidential vs Public Clients
Clients (The app requesting access on your behalf – MVC App, SPA, etc.) are categorized as Confidential and Public clients based on their ability to Authenticate securely with the authorization server (in our case Identity Server).
For example, A Web Application (MVC App) is considered confidential client since it is implemented on secure server and capable of making secure client authentication with Authorization server(through back channel – without the involvement of user-agent or public channel). Also, it can maintain secret tokens (essentially client credentials, access_token and refresh token) which are protected from public access(e.g. by user-agent / resource owner)
Whereas, user-agent-based applications (SPA) and native applications (mobile apps) are considered public clients. This is because the Protocol data and client credentials are easily accessible by resource owner.
Authorization Code Grant
Oauth2 Spec Defines Authorization Code Grant as:
“The authorization code grant type is used to obtain both access tokens and refresh tokens and is optimized for confidential clients. Since this is a redirection-based flow, the client must be capable of interacting with the resource owner's user-agent (typically a web browser) and capable of receiving incoming requests (via redirection) from the authorization server.”
Which simply mean, The Authorization Code flow is optimised for a confidential client interacting with resource-owner via user-agent (browser) capable of receiving and redirecting incoming requests from Auth Server (Identity Server).
In abstract terms – Authorization Code flow has the following sequence,
- Resource-owner authenticates (via –user agent) with authorization server and obtains an authorization_code
- Resource-owner provides Authorization_code to Client (via user-agent after redirection from Authorization server)
- Client authenticates with Authorization server (via back-channel request) and exchanges Authorization_code to get access_token
- the access_token is stored in the Client and the resource-owner is redirected to the appropriate resource
- Since Client (MVC App) has the access_token, it can request for Refresh token from the authorization server (if needed).
- One important point though - In Authorization code flow Resource-owner never get to see(or have access to) Access_token. Client stores it securely.
Implicit grant
Oauth2 Spec Defines Implicit grant as:
“The implicit grant type is used to obtain access tokens (it does not support the issuance of refresh tokens) and is optimized for public clients known to operate a particular redirection URI. These clients are typically implemented in a browser using a scripting language such as JavaScript.
Since this is a redirection-based flow, the client must be capable of interacting with the resource owner's user-agent (typically a web browser) and capable of receiving incoming requests (via redirection) from the authorization server.
Unlike the authorization code grant type, in which the client makes separate requests for authorization and for an access token, the client receives the access token as the result of the authorization request.
The implicit grant type does not include client authentication, and relies on the presence of the resource owner and the registration of the redirection URI. Because the access token is encoded into the redirection URI, it may be exposed to the resource owner and other applications residing on the same device”
Difference between Authorization Code and Implicit?
So the main difference being:
- In Implicit grant, client does not make a separate request for authorization and access token.
- Both Authorization and access token is passed to the resource-owner, encoded into the redirect URI
- This leads to Security vulnerabilities described here https://tools.ietf.org/html/rfc6749#section-10.16
- Due to these security implications, by architecture a Refresh token won’t be issued to public clients (which are incapable of maintaining client secret, therefore Access_token and refresh token)
Do this means that implicit should be used for example by javascript code?
Yes. Due to the above discussed details and as a common practice, most of JS / SPA use Oauth2 implicit flow to secure the application.
(To avoid confusion, please skip this part- There are several variations with this implicit flow. Overall, Oauth2 Specifications are fluid in nature which leads us to several hybrid / custom implementations built along the lines of Oauth2 recommendations. OpenID-Connect address some of the concerns and is relative new (and mature) specification built on top of Oauth2)
the Password grant for ASP.NET MVC application –
Password grant is meant to be used in a scenario where the resource owner has a strong trust relationship with the client (such as native applications). For this use case, the recommended grant type would be Authorization code flow.
Client credentials for Web API –
You are right. Client Credentials grant type is used when the app itself is also the resource owner
Authorization Code for the windows service?
Due to the above stated reasons in spec (user-agent redirection requirement,etc) Authorization code flow won't fit in here. Depending on the type of windows service, I would either use Client Credentials or Password grant type
Can both types cohesist? How do I implement apiKey by using Identity server?
I am not 100 % sure about your requirement here. But if you could post some more details and background about what you want to achieve here . I am pretty sure Brock / Dominick should be able to confirm.
来源：https://stackoverflow.com/questions/35540746/thinktecture-identity-server-client-selection-and-implementation