oauth2: allow client specific token TTLs

[pbarker]

It would be handy if token TTLs could be configured by client, my company is experiencing some use cases where this makes the most sense. Let me know your thoughts, thanks

[pbarker]

Likewise, a client itself should be able to belong to warden groups in some way for machine to machine authentication.

[aeneasr]

Likewise, a client itself should be able to belong to warden groups in some way for machine to machine authentication.

That is possible

It would be handy if token TTLs could be configured by client, my company is experiencing some use cases where this makes the most sense. Let me know your thoughts, thanks

I will think about it!

[aeneasr]

Why do you actually need longer TTLs for specific clients? Can't you use refresh tokens?

[pbarker]

So, the use case for the long TTLs is that some applications have a hard time requerying for tokens, I don't think its a priority right now, but I may whip up a PR for adding the warden groups. Thanks!

[aeneasr]

Keep in mind that access tokens are not session identifiers and must be short living. Additionally, oauth2 libraries exist for every major programming language and hydra implements best practices for mobile apps, including public clients for authorize code flow with refresh tokens.

I'm not sure if I would accept a PR messing with this, especially because we would probably have to change something substantially in fosite.

If it's possible, try to get as far with refresh tokens as possible.

[pbarker]

I agree short lived tokens are necessary, but their duration is somewhat relative. Ultimately, the parameter is configurable. So what about a multi-tenant space? Wouldn't each client want its own limits on the duration of access grants?

[aeneasr]

I'm not confident that one hydra instance is enough to manage a multi-tenant oauth2 set up. In my thinking, you would deploy one instance per tenant and keep them as separate as possible.

[aeneasr]

I feel like the client must be able to deal with this. Access tokens don't make sense if you don't have internet connectivity, thus, they are able to refresh. What use case do you want to cover with this exactly?

[pbarker]

In my thinking, you would deploy one instance per tenant and keep them as separate as possible.

The only issue with that is then trying to make them HA, you have a substantial overhead per tenant. Multi-tenancy seems to work fine if you make the Client ID a URN. I can understand if thats not the aim of this project, but it could definitely be a nice add :)

[aeneasr]

You are making a good point there. Hydra is not designed for multi-tenancy, but if you can make it work then that's perfect :)

[pbarker]

Is fuller multi-tenant support a feature you would consider allowing in the future? Id be happy to at least draw up a manifest to take a look at what it would involve. Thanks

[aeneasr]

Sure, happy to take a look and if it makes sense have that as an official recommendation!

[aeneasr]

Closing this issue, as client TTLs will not be added in the near future and should usually be resolved using the refresh flow. In multi-tenant scenarios, you probably need more than one hydra instance in order to get tenant-specific settings. Separating auth* in multi-tenant scenarios is a good idea anyways.