Storing token/code expiration

[mfzl]

I'm trying to implement a storage layer and as #25 mentions it's a little hard without a reference implementation.

How do I store expiration's for the token?

Looking at fosite.Requester it looks like there's no way to get it. I maybe completely missing the point, since I'm very new to this library.

[aeneasr]

Token expiration date is currently not required for storage retrieval in the storage backend. Instead, the creation timestamp is stored (Request.GetRequestedAt) and each handler can define his own expiry date. The explicit handler, for example, checks for expiry date like this:

    if authorizeRequest.GetRequestedAt().Add(c.AuthCodeLifespan).Before(time.Now()) {
        return errors.New(ErrInvalidRequest)
    }

Where c.AuthCodeLifespan is defined:

// CodeAuthorizeEndpointHandler is a response handler for the Authorize Code grant using the explicit grant type
// as defined in https://tools.ietf.org/html/rfc6749#section-4.1
type AuthorizeExplicitGrantTypeHandler struct {
    AccessTokenStrategy   core.AccessTokenStrategy
    RefreshTokenStrategy  core.RefreshTokenStrategy
    AuthorizeCodeStrategy core.AuthorizeCodeStrategy

    // Store is used to persist session data across requests.
    Store AuthorizeCodeGrantStorage

    // AuthCodeLifespan defines the lifetime of an authorize code.
    AuthCodeLifespan time.Duration

    // AccessTokenLifespan defines the lifetime of an access token.
    AccessTokenLifespan time.Duration
}

and initialized, for example as such:

    explicitHandler := &explicit.AuthorizeExplicitGrantTypeHandler{
        AccessTokenStrategy:   selectedStrategy,
        RefreshTokenStrategy:  selectedStrategy,
        AuthorizeCodeStrategy: selectedStrategy,
        Store:               store,
        AuthCodeLifespan:    time.Minute * 10,
        AccessTokenLifespan: accessTokenLifespan,
    }

Does not storing the expiry date explicitly imply some sort of negative effect on your use case? Or do you see other problems with this approach? I'd be glad to reconsider this portion if issues arise.

[mfzl]

@arekkas Thanks a lot for the quick response.

What I'm trying to implement is a way to create Personal Access Tokens which many (Github, Digital Ocean) have that does not expire, or have a very high value for expiration.

[aeneasr]

I see. I think there are two things you can do:

• Set the lifespan to something huge, e.g. 999999999. This however implies that all tokens issued by the handler (e.g. explicit, implicit, owner, ...) are going to have that long expiry date. It is noteworthy that OAuth2 encourages the use of short lived credentials due to possible compromise of the tokens.
• Write your own handler. This is what I'd recommend to you. Take a look at the implicit handler or the resource owner handler. They are short pieces of code that extend fosites capabilities. You could write a PersonalAccessTokenHandler and give it the functionality you want it to have.

Unfortunately, handlers are not well documented. So if you encounter problems or questions feel free to ask any time. I'm glad to help as best as I can.

[aeneasr]

You can also read up on handlers in the README. I didn't have time yet to document these extensively but I think they are the best fit for what you are trying to achieve. You could define your own storage interface, your own grant_type or response_type (e.g. "personal_access_token") and write custom validation / issuance as well.

I'm actually super glad you came up with that use case. It shows me that extensible handlers are not only abstract overhead but can help in some cases! :D

[mfzl]

Oh yes! :D That will work, to be honest I didn't know I could define my own handlers.

I'm super excited about this library. Few hours back I was very frustrated that I didn't understand. I think I understand the concepts a bit better now.

Thanks a lot, really appreciate it.

[aeneasr]

I'm glad you got past the frustration point! :) If you encounter problems or questions feel free to ask any time. If you have ideas how to lower the frustration bar for newcomers, I honestly appreciate any contributions!

Regarding handler implementation: I can currently only point you to the existing handlers but I think they are a good place to start. If you want to see it live in action, you could modify the example a little bit and add your custom handler type to the factory

[aeneasr]

One more thing: Right now, the handlers are only implementing OAuth2 specific stuff. I wanted to implement an OpenID Connect handler as well but didn't have the time yet. It is therefore quite possible, that the APIs and interface definitions are not as mature as they should be. If you encounter strangeness or something always ask before you waste your time on trying to achieve something that can't work with the current API definitions :)

[mfzl]

Absolutely 👍

[aeneasr]

Hey, this is now implemented without you having to access the handlers :) dfb047d