3

ADFS 3.0 does not support the Implicit Grant client flow of Oauth2, nor does it support client secrets.

Initial investigations suggest it is not secure to use the Authorize Code Grant flow from a native client application as it exposes the client secret but ADFS 3.0 does not suppport client secrets.

Is it possible to use the ADFS's implementation of the Authorize Code Grant flow securely from a native client application? (I'm thinking no).

1
  • When you do not use client credentials, you use grant token that is more secure and supported by ADFS. Commented Oct 13, 2018 at 11:18

1 Answer 1

2

Yes. Using the authorization code flow client side will have almost the same effect as using the implicit grant flow.

There will be a few extra requests but the end result will be the same with some caveats:

  • The implicit flow spec says the token must be in the URL's fragment so it doesn't leave the user-agent. You won't have this with the code flow
  • You should not enable refresh_tokens for the client.

Also the same security concerns as for the implicit flow apply. See RFC6748 section 10.16:

Authenticating resource owners to clients is out of scope for this specification. Any specification that uses the authorization process as a form of delegated end-user authentication to the client (e.g., third-party sign-in service) MUST NOT use the implicit flow without additional security mechanisms that would enable the client to determine if the access token was issued for its use (e.g., audience- restricting the access token).

And on the client credentials front you were already covered:

Native applications that use the authorization code grant type SHOULD do so without using client credentials, due to the native application's inability to keep client credentials confidential.

Footnote: Be sure to read RFC6819 section 4.4.2 to avoid other common implicit flow pitfalls.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .