Make JWT as access tokens optional and replace with a custom strategy

[aeneasr]

[aeneasr]

I think the smartest thing would be to set the generator strategy through an environment variable: OAUTH2_TOKEN_STRATEGY=<strategy> This way, new / custom strategies could be declared and used. For now, two strategies will exist:

• RandomToken: A random 64 char string without self-containing information
• JWT: Use JWT as access tokens

[tbroyer]

Not directly related but I believe you should not store tokens as-is. If the DB data ever leaks, an attacker would have tokens ready to use. FWIW I treat tokens like passwords: a token is in two parts, the first serves as an ID, the second is hashed and only the salt and hash are stored in DB. I have the impression that OSIN would make such storage impractical if not impossible (well, until a few days ago it wouldn't even allow secure storage of client_secrets so definitely OSIN doesn't take security seriously; given how easy OAuth 2 is to get right, I wouldn't bother using a badly-designed framework; YMMV)

[aeneasr]

Yes you're absolutely right. So you're basically storing the token signature in the database and check if the signatures match? I think that's a smart approach but it still bloats requests, doesn't it? We could basically do this with JWT/JWS out of the box.

Regarding securely stored client secrets: I don't think that many companies are doing that right now because passwords are auto-generated and available in cleartext for lifetime. I don't want to imply that I don't see the necessity (securing tokens but not secrets is worthless), just pointing out what I have seen so far.

I saw that client secret encryption was added to osin a few days ago. Osin has terrible error handling which makes it almost impossible to find errors in your request (e.g. forgot to add some parameter or misspelling). Are there any alternatives to Osin out there? I would prefer using a solid framework instead of writing a new one. On the other hand, a solid golang OAuth2 library would be worth the work. Or we could fork / refactor Osin, because it's actually really close (if not completely) to spec with some weaknesses.

One more thing to note is that compromising the machine where hydra-host is running would compromise the whole system as well. You would have access to the encryption keys (or at least know their locations) plus database URL and administrative options like hydra-host client create. But in most cases databases are the leaking pipes and hosts are hard to capture if only one service is open to the net. I've actually thought of enabling client / user create only once and requiring a log in afterwards. But this workflow feels very clumsy.

Sorry if everything is a little random, I'm trying to catch as many ideas as possible :)

[tbroyer]

That's why I didn't talk about compromising the server but only leaking the data (could be a backup, or possibly an eavesdropper on the network)

[aeneasr]

Any ideas how we could make that secure? Thanks by the way for your thoughts, I enjoy these conversations :)

[zsims]

Firstly, awesome project -- thanks for the hard work!

We've been using https://github.com/IdentityServer/IdentityServer3 for a while. And I think it has a good model for token formats, per client setting (for access tokens), identity tokens are always JWTs (per the spec). The only catch is supporting refreshing claims in JWTs is a pain for clients, e.g. you change your email -> self contained JWTs are now invalid. For this reason, opaque tokens are a lot easier for clients. Plus there's no need to sign them, or for clients to check signatures per the JWT (complicated) spec

[aeneasr]

Thanks for the feedback. Access tokens should not contain (privacy and abuse concerns) personal information except the subject which should be a unique & opaque id, changing user data should therefore not render the tokens invalid. Right now, Hydra uses a simple { "jid": "" } claim as refresh tokens and { "sub": "", "exp": "..." ... } as acces tokens. What I have seen now is that many Identity Providers support OpenID Connect. I have to be honest that I have never made use this standard before nor have I, until now, used or seen any library implementing OpenID Connect client features.

I have not yet decided if Hydra's purpose is to offer ID management plus user profile management (/userinfo endpoint) or if it is just a AuthN/AuthZ mechanism. What's cool however is that the Hydra's third party (e.g. connect with dropbox) feature implements capabilities for redirecting to a dedicated login endpoint specified by SIGNUP_URL. This is basically already what Open ID Connect specifies for their login routine and could easily be extended to support the return a identity token. This token could then be used to access a user specified /userinfo endpoint. I will check out Open ID Connect over the next few days and decide if and how this is going to implemented in Hydra.

What's your stand on Open ID Connect?

[tbroyer]

If Hydra's goal is identity management and/or authn (and not just authz) then it SHOULD (MUST?) use OpenID Connect: http://oauth.net/articles/authentication/

[aeneasr]

Thanks for the continued feedback. I took a closer look at OIDC and it should definitely be something to be considered in the connectors (which are currently called providers, see #38 ). Unfortunately, dropbox do not support OIDC so we have to keep OAuth2 -> check user endpoint for at least some of them.

I am in doubt if Hydra should act as a OIDC provider right now. Hydra does offer user accounts and account management and I'm seriously considering to remove this right now or at least put this feature on hold and add a warning to the docs. I will come back with a decision in the next few days.

[ibotty]

What's the current plan regarding OpenID Connect? Should AuthN be outsourced to the providers? Is that feasible?

[aeneasr]

OpenID Connect will be implemented in Hydra by switching from Osin to Fosite (see #46 ). Timeline is not 100% clear yet but I will start implementing once my exams are over which is in ~2 weeks.