> On Jun 24, 2019, at 15:44, Jonathan Vanasco <jonat...@findmeon.com> wrote:
> 
> 
> On Friday, June 21, 2019 at 8:43:32 PM UTC-4, Mike Orr wrote:
> But if  I want to contribute to the enterprise's Single Sign-In, do I need to 
> tell the server the user is still logged into my application so it 
> doesn't expire the SSO account?

No. This is not something that the refresh token/access token is concerned with.

> 
> That is up to your upstream identity provider.
> 
> Your token should be assumed valid until the expiry timestamp. The upstream 
> provider may have it's own protocol where you are supposed to check validity 
> at periodic intervals.
> 
>  
> Do I do this by refreshing the token? 
> No.
>  
> If I do want to refresh the token, do I do it in a NewRequest subscriber? 
> Generally this is done by a background process.  If you want to do it within 
> a Pyramid request, you could do it in a tween or subscriber.

See my question below... you likely don't need to do any refreshing

> 
> The refresh_expire is 60 minutes, so how close to the end should I do 
> the refresh? If a request comes in 10 minutes before the end, I don't 
> know whether the next request will be in 1 second or 20 minutes.
> 
> This is largely an organizational issue on how long you can honor the tokens. 
>  TBH, expiring a refresh in 60 minutes sounds like a bad configuration.  
> Typically an access token would expire in 60 minutes, but the refresh token 
> would expire in 30 days.  That would mean you would need to automatically 
> refresh the access token behind-the-scenes every 60 minutes.
> 

Mike, before you try to go through the whole rigamarole of using the refresh 
token to update the access token, let me ask you an important question:

Are you using the access token after you fetch the initial information about 
the user from Keycloak? If you NEVER ever make another request to Keycloak as 
long as the user is logged in to your Pyramid application, then you don't need 
to worry about refreshing the access token. In which case you can just discard 
it and the refresh token.

If you ever need another access token you'd basically make the user do the 
login dance again. At that point keycloak will go "Ah, but the user is already 
logged in, and already authorized this application" and fast forward back to 
your application, you get a new access token, you contact Keycloak and then 
forget about it ever again.

>  
> What  if the request contains POST data? Would I have to save the data in 
> the session, generate an authorization URL, redirect to the server, 
> come back through the callback view, redirect back to the original 
> URL, and extract the POST data in the session. (Where it's no longer 
> in request.POST.) That sounds like a lot of code overhead. 
> 
> If you need the user to re-authorize because your refresh token expired... 
> you would need to stash the POST data, so that is one way of doing it.  That 
> is a lot of overhead, but should not happen because the refresh token should 
> live longer.

This is the case even if the refresh token hasn't expired. If the user's 
session has expired (for any reason what so ever). It's up to you to decide 
whether to save the users input or if it is lost while they do the login/auth 
dance again.

> 
> I may also have to put a session lock in the site; i.e., Javascript  
> that waits for an idle timeout and puts up a modal dialog, "Do you 
> want to extend your session?" or "Your session is expired. Click here 
> to log in again." How would that interact with tokens and refreshing 
> tokens, since my token processing is in the backend?
> 
> If you have csrf field on the form, that csrf token might have changed. You 
> could update it with javascript.
>  
> How could the  Javascript extend the session or have the user log in again 
> without 
> throwing away a partially-filled-in form? 
> 
> Do the reauth in an ajax request or a browser popup.
>  
> 
> -- 
> 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 pylons-discuss+unsubscr...@googlegroups.com 
> <mailto:pylons-discuss+unsubscr...@googlegroups.com>.
> To post to this group, send email to pylons-discuss@googlegroups.com 
> <mailto:pylons-discuss@googlegroups.com>.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/pylons-discuss/6eb8c654-073d-428d-b404-2fb22d751092%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/pylons-discuss/6eb8c654-073d-428d-b404-2fb22d751092%40googlegroups.com?utm_medium=email&utm_source=footer>.
> For more options, visit https://groups.google.com/d/optout 
> <https://groups.google.com/d/optout>.

-- 
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 pylons-discuss+unsubscr...@googlegroups.com.
To post to this group, send email to pylons-discuss@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/pylons-discuss/BE4C4DF9-7A44-4E3C-9190-3A42C11FA3CE%400x58.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to