doorkeeper: Dynamic (or forever) expiration time? - Single Sign On approaches.

@mmzoo Do you have an email I can send a response to? I have some ideas and suggestions from what I’ve built in the past to handle use cases like auto sign in, auto sign out, handling access tokens when a user changes credentials, knowing about session across applications, etc. I’ve built and thought about all of it before and would love to discuss with you but hate to fill this issue with our implementation details.

Some brief details:

Option 1: Shared data store I know there was an assumption that this is not the case, but if it’s a possibility and all the clients will be behind a firewall it may make sense… This won’t help if a 3rd party app or a mobile app needs to know about the session, but it’s an option. I haven’t gone with this option in the past for those very reasons so I’m not confident I can think out all the pros and cons but some are apparent (having to be behind the firewall, availability of the data store, etc.)

Option 2: Session state

One generic suggestion would be to have the provider calculate an opaque session_state value that is sent to the client along with the user’s information. This session_state would be recalculated every time there’s a change to their session’s status. The client can hit an endpoint sending the session_state it knows about to the server and the server can respond with whether or not the state is still valid. If it’s not valid the client can end the user’s session and perform another handshake with the server to determine whether or not the user is currently signed in. How you store it, when you send it to the provider to determine the session status, etc. is kind of out of scope and hard for me to advise you in with out more intimate knowledge of your specific use case and needs… But generically, that’s one way to do it. As far as making sure the client app I authorized to that information, you could do something like the client credentials flow.

There’s even more ideas in the OpenID Connect Session Management spec. OpenID Connect is primarily an identity layer on top of OAuth 2 but there’s also some good ideas in there for how to handle different use cases like yours.

@mmzoo Are you trying to use access tokens for session management? I urge you to please not.

Since access tokens should only be used to determine if a client application has authorization to act on the user’s behalf it shouldn’t matter how short the access tokens live. The client application can (and should) refresh their access token as needed to continue their authorization to user data (if the provider can determine the user still gives their consent).

Whether or not the user has a session is up to the client to determine. That maybe using by using an access token to get some data back from the provider or another service. But the token itself shouldn’t be an indicator of having a session. IMHO, anything more than about 10 minutes is an irresponsible amount of time to let an access token be considered valid. According to section 5 of the OAuth 2 spec, access tokens should live < 1 hr.

Issue short-lived bearer tokens:  Token servers SHOULD issue
      short-lived (one hour or less) bearer tokens, particularly when
      issuing tokens to clients that run within a web browser or other
      environments where information leakage may occur.  Using
      short-lived bearer tokens can reduce the impact of them being
      leaked.

I need different expiration times for different resource owners or applications, say 10 hours for admins and 2 hours for normal users

Can you talk some about your specific use case? There’s probably another way to tackle the same thing that doesn’t not involve leaving user data open to unauthorized access.

Can we open this issue again?

I need different expiration times for different resource owners or applications, say 10 hours for admins and 2 hours for normal users, just as @felipeelias demonstrated.

Please do not implement a feature like that with no expiration time.

This issue is, in my eyes, not primarily concerned with unlimited expiration time. I agree that that would not be good.

However, the block approach would allow for different expiration times for different users and/or applications rather than one for all. I can e.g. imagine the user checking a checkbox at login saying “This is a public computer, my token should only be valid 10 minutes just for this session” or something like that.

Or, say, 1 hour on mobile devices but 10 hours on desktop clients.

So - I want some kind of dynamic configuration to override the determination of the expiration time in run time (like Facebook’s offline_access), which then supports 0 or some kind of special value to mean “never expires”. What do you think?

@miyagawa Please do not implement a feature like that with no expiration time. Expiring access tokens is a security feature… Not expiring them opens applications to attack. In mobile apps most of all since the access token is actually user accessible and not passed on back channels between two web servers.

Instead you may want to investigate implementing an offline_access feature via a scope. If a client has that scope it should be able to request a new access token with a refresh token even if the user doesn’t have a current session.

You may also want to look at the OpenIDConnect Spec and in particular the section on Offline Access.

I like the block approach! I need to configure the expiration time per consumer (infinite expiry for iphone and 2 hours for web), so this approach would solve my problem, too.