Yes. This was my worry. Unless the oauth server is also an OIDC OP, it has no notion the user login state. That state is held in cookies belonging to a federated provider.
The notion that javascript acting as a client and depends to the user login state is what sets these cases apart. We have to be able to co-ordinate between resource api, AS authorization which builds off of some form of federation/sso. Phil > On Dec 8, 2018, at 6:51 PM, Brock Allen <brockal...@gmail.com> wrote: > > > How would the token endpoint detect login status of the user? > > Oddball idea: why not use the cookie? If the assumption is that the RT is > being used from a client-side browser-based app, and CORS allows for > credentials, then perhaps this is a way to bind the RT to the user's browser > session.. The spec does say that alternative credentials are allowed at the > token endpoint... > > Sounds icky, but compared to iframes back to the authorize endpoint? > > -Brock >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
