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.
