Many of the things you mentioned are specific to Keycloak. I can't answer those.
I can take a deeper look at the oauth details tomorrow. the following are things that just popped at me. On Thursday, May 30, 2019 at 8:57:28 PM UTC-4, Mike Orr wrote: > > - What should I do if there's a state mismatch? I don't want to give > the user an Internal Server Error, or tell them they're bad when > there's nothing they can do about it. > If there is a state mismatch, something very bad happened and you should not let them login. - What should I do with the token? > - Should I save the token in the session? > Are they using oAuth to login to your app every time? If so, you should save it in the database. If they will authorize via oAuth every time they use the app, you could store it in the session or trash it. > - What's the difference between the token keys 'expires_in' and > 'refresh_expires_in'? > expires_in the expiry of the access_token. the auth server will not recognize the access_token after that point. refresh_expires_in the expiry of the refresh_token. the auth server will not issue a new access_token in exchange for the refresh_token after that point. - Should I refresh the token? Where would I do that? In every view > callable? My existing LDAP implementation doesn't have this concept; > it leaves the user logged in until the Pyramid session expires and is > deleted in Redis. > You only refresh the token when it is about to expire. When a user approves your app, the server gives you two secret tokens. You use the access token to make all your requests to the server. That is likely saved in the database and the user's session. Think of it as a "session_id" for the upstream api. You keep the refresh token tucked away in the database. You only use that token to ask for new access tokens. Think of it as an autologin cookie to the upstream api. - I'm instantiating the OAuth2Session in each view. Should I save it > somewhere? I can't put it in the Pyramid session because it's not > JSONable. Is it expensive to reinstantiate it like this? > > You should only require/create it on the login and callback. At the callback, if everything is successful, you can log the user in as a user of your application. -- You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/pylons-discuss/9535c01f-d656-44ad-a81b-5538b4f57c32%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
