Hey there,
We'd like to use a username/password login inside our app alongside an Auth code approach, but it's not possible to extend as of now, because the relevant classes have private constructors and the builders are final. Is the RO password grant something you'd support? We could extend the library and create a PR if that's the case. An alternative approach would be to just make the classes in question protected so that we could implement the grant in question directly in our app without messing with AppAuth.
What do you think?
AFAIK implementation would be adding a username and a password field to the TokenRequest class or extending it and creating a RO version of it.
This is covered in section 4.3.2 of the Oauth2 spec:
https://tools.ietf.org/html/rfc6749#section-4.3
You should be able to create a token request and set the username and password as additional parameters on the builder without having to make any changes. AppAuth is primarily focused on the third party auth case where the auth code flow is recommended, so I don't know if we'll add explicit support for user credential token requests. However, if you send us a pull request with the necessary changes to the token request object I'll consider it.
@iainmcgin we've tried (together with @hallerio) to add the username and password field as additional parameters, and it worked perfectly! So thank you for the info.
But there is still an issue: we can't refresh the token by calling the performActionWithFreshTokens method on the AuthState object as it would require to have the last authorization request which does not exist in this case. Do you have any plans to add this kind of support (getting the parameters from the last token request maybe) or will you also consider this change if we send a a pull request?
The danger in making that change in your case would be that you need to retain the user's plain text password over long periods of time for the purpose of retrieving new credentials. This could be potentially dangerous; it would be better if you could instead acquire a refresh token so the password can be discarded as soon as possible. Because of this preference, it's unlikely that I would accept a change that makes dangerous access token usage patterns easier.
It shouldn't be too difficult for you to build your own token refreshing helper if you want to stick to this approach, but I would strongly recommend investigating an alternative flow where you can acquire a refresh token instead.
@zoltanhomoki did you implement the ROPC call without having to make modifications in the library?
@parakhj we've created only a PoC and we've implemented ROPC on top of the base layer of AppAuth, so we don't use the AuthState we have our own solution for that.
Hey there,
I want to implement the same grant type, (log in users with username and password using the AppAuth-Android SDK)...
Please, do you have any change since 2017?
Any new idea/ suggestion how to implement it?
Thank you in advance!
Most helpful comment
Hey there,
I want to implement the same grant type, (log in users with username and password using the AppAuth-Android SDK)...
Please, do you have any change since 2017?
Any new idea/ suggestion how to implement it?
Thank you in advance!