CODEWITHSUNDEEP
oauthpermissionsoauth-2.0jwt
wkstar
wkstar

Reputation: 265

oAuth2 Mobile App Grant

I'm building a native Mobile App that connects to a REST API. I'm looking at this demo oAuth App to use as a guide for my Authentication/Authorisation layer.

When the user comes to the App for the first time I want to provide them with a username and password box. After they hit submit I want to the App to be supplied with an access token, and a list of permissions (scopes?) that the user is permitted to perform.

I've read lots about the oAuth2 specification but am confused as to which flow to use.

I can't use the Resource Owner Password Credentials Grant because I can't trust the Native App with the Client Secret.

I don't want to use the Implicit Grant, as I don't want to present the user with a "Do you authorise this App?" web window.

I've looked into the JWT Bearer flow, and think it might be what I need as it doesn't require the Client ID/Secret. However I can't find any examples where this flow returns permissions (scopes?) that the user can perform.

Edit #1:

I am confused as to the use of Scope. The specification says-

The authorization server MAY fully or partially ignore the scope requested by the client, based on the authorization server policy or the resource owner's instructions. If the issued access token scope is different from the one requested by the client, the authorization server MUST include the "scope" response parameter to inform the client of the actual scope granted.

If the client omits the scope parameter when requesting authorization, the authorization server MUST either process the request using a pre-defined default value or fail the request indicating an invalid scope. The authorization server SHOULD document its scope requirements and default value (if defined).

From that can my Client request a list of ALL Scopes, and then the Authorization Server give a Response with the ones the User actually has?

Thanks for your help, Tom.

Upvotes: 0

Views: 855

Answers (1)

Hans Z.
Hans Z.

Reputation: 53908

You list two assumptions about OAuth 2.0 flows that are not true:

  • the Resource Owner Password Credentials Grant can be used with a public client i.e. a native app that doesn't have a client secret

  • usage of the Implicit Grant does does not imply that it requires explicit consent; that is to the discretion of the Authorization Server implementation; in an enterprise setting or a setting where the same party controls the client and the Authorization Server, that may be omitted

But since the Implicit grant comes with security considerations, for native apps it is typically better to use the Authorization Code grant.

Scopes are a way for the Client to request certain permissions. The Resource Owner can grant the Client permissions that relate to these scopes (explicitly or implicitly). Since the Client will change its behaviour based on what permissions it gets, it is assumed that there's some shared understanding between Client, Resource Server and Authorization Server about what Scopes related to. There's no predefined semantics in the OAuth 2.0 specification, it is up to the implementation.

Upvotes: 2

Related Questions