Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

oauth2: allow client specific token TTLs #428

Closed
pbarker opened this issue Apr 17, 2017 · 13 comments

Comments

@pbarker
Copy link
Contributor

commented Apr 17, 2017

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

This comment has been minimized.

Copy link
Contributor Author

commented Apr 17, 2017

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

@aeneasr

This comment has been minimized.

Copy link
Member

commented Apr 17, 2017

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

This comment has been minimized.

Copy link
Member

commented Apr 17, 2017

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

@pbarker

This comment has been minimized.

Copy link
Contributor Author

commented Apr 20, 2017

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

This comment has been minimized.

Copy link
Member

commented Apr 20, 2017

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

This comment has been minimized.

Copy link
Contributor Author

commented Apr 20, 2017

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

This comment has been minimized.

Copy link
Member

commented Apr 21, 2017

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

This comment has been minimized.

Copy link
Member

commented Apr 21, 2017

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

This comment has been minimized.

Copy link
Contributor Author

commented Apr 21, 2017

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

This comment has been minimized.

Copy link
Member

commented Apr 21, 2017

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

This comment has been minimized.

Copy link
Contributor Author

commented Apr 21, 2017

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

This comment has been minimized.

Copy link
Member

commented Apr 21, 2017

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

@aeneasr aeneasr changed the title Client specific token TTLs oauth2: allow client specific token TTLs Jun 5, 2017
@aeneasr aeneasr added this to the unplanned milestone Jun 5, 2017
@aeneasr

This comment has been minimized.

Copy link
Member

commented Jun 5, 2017

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.

@aeneasr aeneasr closed this Jun 5, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.