2

I have been doing quite a lot of research on this topic and I am left a little confused on how to go about it. My understanding is this:

To use Identity Server 4 with an android app, the best approach is to have the android app open an embedded browser instance that will render the identity server login page for the user where the user can log in. Upon the completion, the browser will close and a method will be called on the app to pass in the token(s) that are needed to access the apis and claims and what not. Now the part that confuses is me what type of client are we to use to accomplish this and what would the configuration for that client look like?

Here is a diagram of what I described above, if this is wrong please feel free to correct me.

App Identity Flow
The article where I got it from is: https://datatracker.ietf.org/doc/html/draft-ietf-oauth-native-apps-09#section-4.1

I am using nativescript to build my app and I'm putting that out there because I'm not sure how much that will matter, so if you think it does please mention why.

The Implicit client is used for SPA applications and that is one of the clients I already have setup and working with my angular app. Now I'm trying to get it to work with the native script app but the options from what I'm reading are either GrantTypes.Hybrid or GrantTypes.Code Some of the answers I found say we should use Hybrid and others are saying we should use Code and I'm not sure which is correct and why?

The other thing that bothers me is how this is secure on the android app. With SPA and Implicit flow, we define the login and logout urls and as such those domains are white listed and will not work with any other which makes it secure. However, with android app how exactly does this gets secure? I can't store a secret on the phone because anyone then can dig it out, so what exactly about the flow (Hyrbrid or Code, depending on which I'm suppose to use) keeps it seure?

Community
  • 1
  • 1
Bagzli
  • 6,254
  • 17
  • 80
  • 163
  • Check the openAuth method of the new InAppBrowser plugin for NativeScript => https://github.com/proyecto26/nativescript-inappbrowser – jdnichollsc May 10 '19 at 23:03

3 Answers3

2

It may be too late to answer this post, but I think it can be useful for other readers of this post.

Summarized Answer:

It is better not to use implicit flow in this case.
You should use one of the Hybrid or Authorization Code flows and it all depends on how important is security in your application?
In fact, you should do a trade-off between security and performance. If security is more important to you, you should use the Hybrid flow, which mitigates a number of attacks that apply to the browser channel such as Code Substitution. But this flow creates a performance overhead to provide more security for your application as well as your IDP.
If a balanced level of security is sufficient for your application, it is better to use the Authorization Code flow.

More Detailed Answer:

The Hybrid flow uses the ID Token that includes c_hash (which is a hash of the authorization_code returned to bind authorization_code to the state (which is linked to the session itself).
According to this article:

OpenID Connect’s hybrid flow falls into this category as well and mitigates the attack fine. OpenID Connect clients send a nonce in the request. At the same time, the nonce is stored in the session that is linked to the state. The nonce will be returned in a signed ID Token unchanged, so the ID Token and the state are linked through the session. The ID Token also includes c_hash, which is a hash of the code returned. Thus, the code and the session are also bound. If the adversary just swaps the code, the value of c_hash will not match and the attack will be detected. Even if the adversary swaps both code and ID Token, the attack will not work since the nonce in the ID Token and the session will not match.

Milad Rashidi
  • 1,296
  • 4
  • 22
  • 40
1

For the flow you are describing you should use the "Implicit Grant Type". Unfortunately, though, unlike with a remote server URL, "there is no reliable way to ensure that the binding between a given redirect URI and a specific mobile application is honored." (from What's the right OAuth 2.0 flow for a mobile app).

As said in https://oauth.net/2/grant-types/implicit/, "it is generally not recommended to use the implicit flow (and some servers prohibit this flow entirely). In the time since the spec was originally written, the industry best practice has changed to recommend that public clients should use the authorization code flow with the PKCE extension instead."

For detailed information about PKCE, see Proof Key for Code Exchange by OAuth Public Clients.

Community
  • 1
  • 1
Jorge Cavaleiro Dias
  • 311
  • 1
  • 7
0

You can return the code via query string param redirecting the users to the app again using deep linking:

  • Android Url: my-demo://demo/callback?code=123...
  • iOS Url: my-demo://callback?code=123...

For this you can use the openAuth method of the new InAppBrowser plugin => https://github.com/proyecto26/nativescript-inappbrowser

For more details about the security, you can see this thread => https://github.com/NativeScript/NativeScript/issues/6923#issuecomment-473792810

jdnichollsc
  • 1,520
  • 1
  • 24
  • 44