Nov 5th, 2012, 11:23 AM
Implicit user authorization
I have seen in the spring-oauth sparklr demo that there is a provision to have auto-approved clients. I am trying to have a session established when a user uses the Resource Owner Credentials flow to "login" and have the server automatically approve a client if the user is logged in. This seems to be a pretty common flow, and I understand how this can be done through a web login, but I am unable to see how "sessions" are established when the user "logs in" and gets a token using the resource owner credentials flow for native/mobile clients. How is the user "remembered" in such cases when he asks for an authorization code? I would appreciate any pointers.
Nov 5th, 2012, 03:47 PM
It's not really clear what is meant by a "user session" in the context of a password grant - I suppose the access token itself pretty much embodies everything you could possibly know about the authenticated user, and the client. In the case of the auth code grant there is a browser, an authentication and the possiblity to link them together with a cookie. I don't immediately see any such possibility with a native client (but that's not my speciality so please help me out if there is something that I am missing).
Nov 5th, 2012, 05:51 PM
Is it ok to make the assumption that with the auth code grant, there is always a browser? I may be attempting something really weird, but I am trying to see if the browser login step can be replaced by the resource owner password credentials grant. I think if something like that was possible, then it would become a lot easier for native apps/mobile clients to implement the auth_code flow. Sorry if I am unable to make my question clear.
Originally Posted by Dave Syer
Nov 6th, 2012, 08:15 AM
I suppose there's no reason a native client can't do an authcode flow - it just has to behave like a browser (follow redirects, store and re-present cookies). And it has to know how to authenticate (which isn't defined by the spec but browsers have an easy time of it because they do rendering and things that make the process work for users).
For servers that *have* passwords, the password flow seems to be quite common for native clients, but that's too restrictive for a lot of modern use cases. Like I said though, I don't do mobile development, and the only native client I support we do it with an implicit grant at the moment. We are discussing whether it makes sense to modify the password flow to accept other credentials, but that is a slippery slope - you say you support passwrod grant, but actually it's not quite, so clients will not know what to do.
Still confused by your requirement - if you want to use a password grant then you won't be using authcode (they are mutually exclusive).
Last edited by Dave Syer; Nov 7th, 2012 at 03:04 AM.
Nov 6th, 2012, 11:28 AM
I agree, the two grants are mutually exclusive if my intent was to use them both as grants. I think I am trying something which probably doesn't fit in well here. My intent was to use the auth_code flow, but in that flow, instead of using the browser to have the user login, my intent was to have the user authenticate using the password grant. That is probably the wrong approach. Just having a tough time trying to understand how to adapt OAuth to cases other than web/browser flows. I appreciate your replies.
Originally Posted by Dave Syer