locked
Securing a Web API with SSO server RRS feed

  • Question

  • User-1329202585 posted

    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.

    Thanks

    Tuesday, September 15, 2015 8:32 PM

Answers

  • User1779161005 posted

    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.

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Wednesday, September 16, 2015 5:12 PM

All replies

  • User1779161005 posted

    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.

    Tuesday, September 15, 2015 8:40 PM
  • User-1329202585 posted

    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!

    Tuesday, September 15, 2015 9:04 PM
  • User1779161005 posted

    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 does).

    Wednesday, September 16, 2015 10:51 AM
  • User-1329202585 posted

    Can you get refresh tokens for implicit flow?

    Wednesday, September 16, 2015 4:56 PM
  • User1779161005 posted

    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.

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Wednesday, September 16, 2015 5:12 PM