Last post Sep 16, 2015 05:12 PM by BrockAllen
Sep 15, 2015 08:32 PM|falconmick|LINK
Hi all, I've been doing research recently into how to implement SSO using a separate server to log users in.
So far I've done allot of looking into Open ID Connect using Identity Server 3, it looks really cool so far, but unfortunately the approach that is recommended uses browser windows, of which I don't particularly want to use as I just want to submit the login
credentials via a form inside of an app OR inside of a form in a MVC page. I understand that there is the resource owner password credentials grant flow, but I keep getting allot of people talking it down. Also all of the guides I have read really down talk
it and suggest it's not a good flow to use. Also allot of the docs have it suggesting that the resource owner enters the credentials into the app (client) and then the app posts this info to the auth server. In my situation it would be the user posts to the
app then to a Web API then the we API submits the un/pw and retrieves claims from the identity server, of which it then consumes to produce it's own bearer token.
Is the above custom flow I have described viable? Or should I really be looking at another approach of Federated Authorization.
Sep 15, 2015 08:40 PM|BrockAllen|LINK
You can use resource owner password flow, it's just that if you're done any work in the token service to do things like 2fa or any custom workflow for logging in, then you don't get that when you use resource owner password flow. You also lose out on single
signon by using resource owner password flow.
Sep 15, 2015 09:04 PM|falconmick|LINK
Well I would say that your the expert, so I will ask for an expert opinion.
You are developing a game for Iphone. You need to log the user in and want to make it so across all of your suite of games your user can sign in using the same account for any of your games. Do you:
A. Utilize Implicit Flow as it is an non trusted client. Make the token long lived so the user doesn't have to re-login over and over.
B. Use Authorization Code Grant because you want to have short lived tokens that you periodically refresh via the refresh token. Even though it's not a trusted Client
C. Use resource owner password flow because you want 100% in game login with no external flows in browser
D. Utilize another methodology for user Authorization because none of the above fit the requirements.
The system would work roughly like so, a user runs a native client which talks to an Web API 2 server which talks to the auth server. If we use A or B, client would also talk to auth server
Thanks for your help, I could probably find all these things out via trial by fire, but getting advice from the author of the system your looking to implement sounds allot less painful!
Sep 16, 2015 10:51 AM|BrockAllen|LINK
Don't use resource owner for 3rd party clients -- the user should not trust those apps with their password. As for long lived access, you can either use refresh tokens or use long lived reference tokens if your token service supports that (IdentityServer
Sep 16, 2015 04:56 PM|falconmick|LINK
Can you get refresh tokens for implicit flow?
Sep 16, 2015 05:12 PM|BrockAllen|LINK
No, only with code flow. But you probably don't need them. You can use long lived reference tokens, or you can use a helper library to keep renewing access tokens from your JS app.