3

I have an android native app as client and spring boot service in the backend with REST endpoints. I want to know the best possible strategy for authentication with oAuth2 (without the social login approach).

I am currently using spring oauth security & have an authorization server up and running(user signs up with email & password). I use the grant type "password" to get access tokens in the android app. However, this approach requires the android app to send the client ID & secret in the request. I read a few posts which suggest that this grant type is not ideal. I dont mind receiving the user's password, but i think storing the client secret in the app is not a good approach.

Another approach would be to use the Authorization Code grant flow, but in this case since i only have a native app & backend APIs, i dont know how to authorize the user. It doesn't seem like a seamless experience for users to see a browser page asking them to authorize the app. Which doesnt make sense also because this is no third party app.

I found a post where people suggest using Authorization Code flow with PKCE. But this apparently doesn't yet work with spring.

So, now i am left wondering how other native mobile apps, handle authentication? Do they not use access token? How best can i support authentication when dealing with a mobile app & spring backend?

jzheaux
  • 7,042
  • 3
  • 22
  • 36
user3770825
  • 49
  • 4

1 Answers1

2

Spring Security OAuth supports password and authorization_code flows without the client secret, meaning a "public client". Since you own the Authorization Server and the native app and you are okay with the native app taking credentials, it's reasonable to have your native app use a public client with the password grant type.

If you decide that your native app shouldn't take credentials, though, then PKCE is the current best practice. Using the authorization_code flow with a public client is the recommended alternative to PKCE:

In the time since the spec was originally written, the industry best practice has changed to recommend using the authorization code flow with no secret for native apps.

And this would mean, as you mentioned, jumping out to a browser.

jzheaux
  • 7,042
  • 3
  • 22
  • 36
  • So i suppose the traditional oauth cannot be used as it is in mobile clients. And i would have to choose between security(not having user go through a browser) and usability if i want to employ oauth for mobile client. I haven't seen a single app jump out to a browser to authorize unless ofcourse one is trying to login from different service provider(google, facebook), so what kind of authentication mechanism do apps generally use? – user3770825 Mar 28 '19 at 07:45
  • Sorry, I'm not clear on how the answer doesn't address your follow-up question. If you own the Authorization Server and the native app and you are okay with accepting creds in your app, then OAuth supports the password grant with a public client (one without secrets). Does that not address your concern? – jzheaux Mar 28 '19 at 11:48
  • Thanks for the info, this is actually what i needed. But i couldnt find a working example of this approach. i.e, using a password grant with public client. Do i now send the client_id as argument along with the user credentials in a x-www-form-urlencoded request?or not send it at all? neither of these worked for me. – user3770825 Mar 30 '19 at 19:59
  • I think this is a new question, which is fine, but I'd recommend asking it in its own SO question. The reason for that is so that folks who have this question (using a password grant with a public client) can find that more easily when googling for it. Feel free to link that here. The quick (probably incomplete) answer to your question is that client authentication is done with Basic authentication by default, so you'd likely want to send it that way. If your original question (how can I best ...) is answered, please accept this answer, again so that folks can find it more easily. – jzheaux Mar 30 '19 at 20:11
  • I tried the solutions mentioned in the tagged link and none of them worked for me and i keep getting a 401. – user3770825 Mar 30 '19 at 20:11