andretietz/retroauth

Best way to implement "Anonymous" access (OAauth client_credentials)

ChrisTitos opened this issue · 4 comments

Hi,

Up to now my app has only used this library to login a user. However, I'm now adding a "sign up" functionality, and for this I need anonymous access to my API using the OAuth client_credentials grant.

My guess is define a different token type. But it seems this library will always open a Login Activity? But I don't need an activity for this case (plus, the Login activity is already opened because the "sign up" button is in that activity).

Any suggestions?

The user is not signed in and you have anonymous accesscredentials? where do they come from? hardcoded and shipped with the app?

if so, then don't use the @Authenticated annotation but add them as a retrofit header (@Header)

if you need to request them and store them as different token type, you can use the parameter token type with the @Authenticated annotation:
https://github.com/andretietz/retroauth/blob/master/retroauth/src/main/java/com/andretietz/retroauth/Authenticated.kt

  • The token type can be defined in your Authenticator implementation.

Whenever your LoginActivity opens, you check which token type was requested (AuthenticationActivity#getRequestedTokenType())

Depending in that you either request your anonymous token, finalize(finalizeAuthentication) and close the activity or you leave it open for the user to login as usual.

That should do the job

Did this help?

Maybe "userless" is a better term than anonymous. If the user is not logged in, the app itself still needs to make calls to the API, and for that it still needs to get an access token via OAuth (via the client credentials grant).
For this no user interaction is required, so I don't want to open a Login screen (even if I immediately close it, you still get a flash). Also, the primary use case here is a user sign-up, and in this case I am already in the LoginActivity (from there the user clicks on "create account" and goes to the sign-up flow), so you could get weird situations.

So yes, a token type seems to be one part of the solution, but if I could then do something like:

TokenType A (user, interaction required) -> open login screen
TokenType B (userless, no interaction required) -> directly call the login logic

ok, then just don't use the authenticated annotation but a manually set header.