What are the implications of the authorization endpoint issuing the access token?

Question

My understanding is that in a standard OAuth flow, the access token is issued by the token endpoint, and the ID token is issued by the authorization endpoint.

In Azure AD, there's an option to have the access token issued by the authorization endpoint instead. Are there security (or other) issues with doing this when not using an implicit flow?

Answer 1

In implicit flow, access tokens are issued by the /authorize endpoint of the authorization server. So if your app is not obtaining access tokens from the /authorize endpoint, you are not leveraging the implicit flow by definition.

You shouldn't be using implicit flow with Azure AD anymore. Implicit flow is less secure for several reasons: the client application does not authenticate itself, the tokens are acquired through the front channel, response in the query parameters leaks into the browser history and etc. Implicit flow was originally meant to support native and browser apps (i.e. public client apps), since they have no means to contain a secret that could be used to prove their identity. Azure AD now supports the Proof Key for Code Exchange (PKCE) extension for the authorization code flow, which provides a workaround for public client apps to leverage the authorization code flow (which is more secure).

Hybrid flow (where your app receives the ID token from the /authorize endpoint and the access token from the /token endpoint), on the other hand, is fine -as long as your app runs on HTTPS. ID token is only meant for your own application (i.e. the app that acquires it) for the purpose of identifying the user (to update the UI and etc.), so from a security standpoint, it's not as crucial (of course, never make authorization decisions based on ID tokens).