• r

    rp

    2 years ago
    The best practice for using federated login providers is to use the authorisation code grant flow (in OAuth) which requires you to manage sessions by yourself.
  • ?

    user

    2 years ago
    wait why would I manage sessions though, the log in provider is already doing that
  • ?

    user

    2 years ago
    like as a user going to google, I can see this:
  • ?

    user

    2 years ago
    Also you wouldn't need the auth code flow unless you were planning on impersonating the user or use their data in the back channel
  • r

    rp

    2 years ago
    That's google managing it's own sessions.. which is differently handled than "sign in with google"
  • ?

    user

    2 years ago
    but if you just need it for log in, I assume you would use the replacement for implicit grant, since that is dead
  • ?

    user

    2 years ago
    If I'm a user those sessions are 1:1, aren't they?
  • r

    rp

    2 years ago
    Also you wouldn't need the auth code flow unless you were planning on impersonating the user or use their data in the back channel True. But in this case, you would only use the tokens to identify the user and then throw them away. After identifying the user, you would use your own session management solution to take proper control of it. Just like how google, fb, youtube etc etc do for their own website.
  • r

    rp

    2 years ago
    So as per my understanding, you are curios about why you need your own sessions as opposed to just using the id token provided to you by a third party login provider. Is this correct?
  • ?

    user

    2 years ago
    well access token not id token, but yes