Integrating with Hydra
Jan Olszak
Aeneas Rekkas
Good point. There's no official SDK yet (feel free to write one!). but there's some code and some docs on this topic:
guide: https://ory-am.gitbooks.io/hydra/content/oauth2.html#authentication-flow
code: https://github.com/ory-am/hydra-idp-react/blob/master/src/common/service/hydra.js
hydra.js basically logs in using the `client_credentials` grant,
then fetches the public and private key for signature verification
/ signature creation (`verifyConsentChallenge`,
`generateConsentToken`) and passes some
claims (documented in the guide) to a jwt library.
if you integrate it would be great if you would write down things that are hard to implement or understand. docs are always a team effort :)
once the token is created, the client is redirected back to hydra. the url can be extracted from the consent challenge.
let me know if that helps
--
You received this message because you are subscribed to the Google Groups "ory-hydra" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ory-hydra+...@googlegroups.com.
To post to this group, send email to ory-...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ory-hydra/b8686d91-701a-4256-abc7-43f8be8858c0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Aeneas Rekkas
to consume the oauth2 tokens you can use whatever you like. passport.js is a common choice for javascript and https://github.com/golang/oauth2 for golang
on the resource server side you will have to make a request to hydra every time you want to check token validity. the warden is somewhat documented: https://ory-am.gitbooks.io/hydra/content/policy.html
this is by the way why low latency is important for hydra. in the
future, we might be able to issue JWTs to avoid this. spec however
does not consider JWT for access tokens best practice as they can
not be revoked etc.
the difference between ActionAllowed
and Authorized
is that Authorized only checks if the token is valid. There's
no policy decision involved (that's what ActionAllowed does).
in the code the warden is used almost everywhere: https://github.com/ory-am/hydra/blob/master/client/handler.go#L49-L58
in a go resource server this would look the same, using the HTTPWarden implementation: https://github.com/ory-am/hydra/blob/master/warden/warden_http.go
unless you use some self-built rbac or ACL you will also need to
manage policies, a good place to start is `hydra help policies`
Jan Olszak
Aeneas Rekkas
> 1. Account creation
Hydra does not play a role here. You could however protect the endpoint using hydra (only requests with a valid OAuth2 token can create accounts)
Hydra does not play a role here. You could however protect the endpoint using hydra (only requests with a valid OAuth2 token can delete accounts)
1. the user logs in and receives e.g. a session cookie. hydra does not play any role in this
2. some app (client) requests access to a users resources using OAuth2. because the user needs to consent to this access, he must log in. this is the "authentication flow" :)
> - Is it possible to avoid HTTP communication and talk directly with the database. Maybe via ladon?
I can not stress it enough, here is an exemplary identity provider and login / consent endpoint. take a look at the code (it's just a few files): https://github.com/ory-am/hydra-idp-react/tree/master/src
There's an exemplary user service: https://github.com/ory-am/hydra-idp-react/blob/master/src/common/service/userService.js
this is the place where you would add account creation and removal stuff.
--
You received this message because you are subscribed to the Google Groups "ory-hydra" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ory-hydra+...@googlegroups.com.
To post to this group, send email to ory-...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ory-hydra/f03b6be2-7e94-406b-9fda-0226a6a70311%40googlegroups.com.
Aeneas Rekkas
Here's a use case: ToDo List. I hope this clarifies things :)
ToDo has a login endpoint (todo.com/login). The login endpoint written in node and uses mongodb to store user information (email + password + settings). There are other services as well: list management (close, create, move), item management (mark solved, add). You are using cookies to see which user is doing the request.
Because you want to open up your APIs to other developers, you
decide to use OAuth2. Another reason might be that you want to
have a mobile client. Another may be that you have to do
cross-origin requests where you can't use session cookies. Maybe
you want to write an in-browser client. Or you want to use OAuth2
because tokens are limited in time and thus more secure. These are
only a couple of reasons to use OAuth2. I believe that using
OAuth2 as your primary protocol for authorization is smart. That
way there is only one protocol you need to take care of and you
can open up your APIs to other devs in no-time.
Now you install Hydra in your cluster. You can immediately set up new OAuth2 clients. However, if an app wants access to a user's todo lists, that user needs to give his consent. This is where https://ory-am.gitbooks.io/hydra/content/oauth2.html#authentication-flow comes in to play. Hydra needs to know WHICH user is giving consent. To do so, Hydra redirects to the login endpoint and issues a challenge. The login endpoint authenticates the user and asks for his consent ("Do you want to access MyCoolAnalyticsApp access to all your todo lists?"). After consenting, the login endpoint redirects back to hydra and appends a consent token. That consent token is verified and analyzed by hydra. the information extracted is used to issue an access token.
Now, everytime a request hits that contains an access token, you make a request to hydra and ask who the token's subject (user) is and if the token is valid. Additionally, you can ask if the token has permission to perform a certain action.
I hope this makes things clearer. Because I want to improve the docs, could you answer a few questions?
- did you understand the example?
- did you read the entire Guide (gitbook) and the API reference (apiary)?
- does the example layed out here explain things better than the docs?
- did you look at the react example? (if not, why not? missing docs? missing link?)
thanks!
--
You received this message because you are subscribed to the Google Groups "ory-hydra" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ory-hydra+...@googlegroups.com.
To post to this group, send email to ory-...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ory-hydra/f03b6be2-7e94-406b-9fda-0226a6a70311%40googlegroups.com.
Jan Olszak
Aeneas Rekkas
Exactly! :) I chose this path because it makes it much easier to put hydra on top of existing environments. And you're free to authenticate your users any way you like (username/password, sms, email, qr code, ...)
--
You received this message because you are subscribed to the Google Groups "ory-hydra" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ory-hydra+...@googlegroups.com.
To post to this group, send email to ory-...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ory-hydra/6a452abb-45b0-427a-93c0-94acfe50d4f8%40googlegroups.com.
Jan Olszak
On Tuesday, May 31, 2016 at 11:57:01 PM UTC+2, aeneas wrote:
Here's a use case: ToDo List. I hope this clarifies things :)
ToDo has a login endpoint (todo.com/login). The login endpoint written in node and uses mongodb to store user information (email + password + settings). There are other services as well: list management (close, create, move), item management (mark solved, add). You are using cookies to see which user is doing the request.
Because you want to open up your APIs to other developers, you decide to use OAuth2. Another reason might be that you want to have a mobile client. Another may be that you have to do cross-origin requests where you can't use session cookies. Maybe you want to write an in-browser client. Or you want to use OAuth2 because tokens are limited in time and thus more secure. These are only a couple of reasons to use OAuth2. I believe that using OAuth2 as your primary protocol for authorization is smart. That way there is only one protocol you need to take care of and you can open up your APIs to other devs in no-time.
Now you install Hydra in your cluster. You can immediately set up new OAuth2 clients. However, if an app wants access to a user's todo lists, that user needs to give his consent. This is where https://ory-am.gitbooks.io/hydra/content/oauth2.html#authentication-flow comes in to play. Hydra needs to know WHICH user is giving consent. To do so, Hydra redirects to the login endpoint and issues a challenge. The login endpoint authenticates the user and asks for his consent ("Do you want to access MyCoolAnalyticsApp access to all your todo lists?"). After consenting, the login endpoint redirects back to hydra and appends a consent token. That consent token is verified and analyzed by hydra. the information extracted is used to issue an access token.
Now, everytime a request hits that contains an access token, you make a request to hydra and ask who the token's subject (user) is and if the token is valid. Additionally, you can ask if the token has permission to perform a certain action.
I hope this makes things clearer. Because I want to improve the docs, could you answer a few questions?
- did you understand the example?
- did you read the entire Guide (gitbook) and the API reference (apiary)?
- does the example layed out here explain things better than the docs?
- did you look at the react example? (if not, why not? missing docs? missing link?)
Jan Olszak
Aeneas Rekkas
Yes, ladon wraps this. Yes you can do it locally - but you'd
still have the database roundtrip!
On top of that, you need to validate and look up the access
token. To validate the access token, you need the $SYSTEM_SECRET.
to reduce security risk, only hydra should know the system secret.
--
You received this message because you are subscribed to the Google Groups "ory-hydra" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ory-hydra+...@googlegroups.com.
To post to this group, send email to ory-...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ory-hydra/9064cc6a-8819-441e-a546-56d60e17c487%40googlegroups.com.
Jan Olszak
Aeneas Rekkas
> Well, database connections scale much better then rest services.
Depends on the database and the amount of data! :)
> Sharing SYSTEM_SECRET with the Resource Server is ok.
It's not! Hydra uses the SYSTEM_SECRET to encrypt private keys at rest. The SYSTEM_SECRET is used to issue new access tokens as well. Leakage of the SYSTEM_SECRET will cause system-wide vulnerabilities.
> If the attacker got there he probably doesn't care about any tokens (he already has access to the protected resources)
That's the point of splitting up resource servers and authorization. If the attacker manages to break into one resource service, he's still shut off from the rest of the services. If you directly connect to the authentication db and have the SYSTEM_SECRET, the attacker can issue new access tokens, he can read and write private keys (that's extremly bad). For your securities sake: Don't do it!
If
you fear that latency will become an issue: Try using the
existing endpoints. If you see that latency is too high, we will
figure out a way to resolve this. We could introduce JWTs as
access tokens, we could use AMPQ, Protobuf, ... for token
lookup. We can figure out a better architectual concept: e.g.
all requests pass a gateway that is running on the same host as
hydra before being proxied to a trusted subnet, where the
resource servers are.
There
are so many possibilities to resolve latency issues! Don't
sacrifice security because of something that isn't a problem yet
:)
To view this discussion on the web visit https://groups.google.com/d/msgid/ory-hydra/98cb45a6-984f-467d-978c-d06489dcf9ed%40googlegroups.com.
in...@icod.de
Ok with hydra I can create clients and their secrets.
Fine. That's oauth2 stuff.
What confuses me is this "consent".
It's not documented in openid-connect.
You're saying it also handles oidc requests.
But how can it handle oidc requests when it doesn't have a userbase?
With coreos/dex, it's pretty much clear what it does.
You can create users with email&password and create clients with secrets.
And then you can go through the dance with JWT and the 3 flows.
Pretty straightforward.
So now there's hydra.
Seems like it's not meant to act as an IDP.
It's more of an oauth2 access manager, what oauth2's role is traditionally.
User has resource
User wants to give some client_id access to this resource.
Client_id asks user if it can have access.
Yes says yes.
Access is granted in hydra.
Fine.
But how do I manage access?
Through hydra? With the sdk?
Eh. Idk.
Ok concrete example.
I'm writing an auth backend server.
It uses protobuf to communicate.
I can create users, passwords, email codes, reset codes, verify those, update and remove users.
All good.
It also has a client to access those rpc methods.
Now I've written a stub project.
The stub project has everything to deal with user registration, login, email confirmation, forgot password and reset password.
My goal is to have a central userdb.
And now I need something to manage access to resources.
Hydra sounds like a good fit.
So I have my authserver running,
and I have hydra running on the same machine.
New project. I clone the stub and start writing handlers and UI and models.
I want:
- users to be able to use oidc to sign up with my new project or use traditional login/password
hydra isn't for this, there are other libs.
- act as an oidc provider
- act as an oauth2 authorization server
nginx is on the front
I do a simple proxy request to my stub project
location / {
proxy_pass 127.0.0.1:port;
}
where is hydra in this?
which endpoints do I have to proxy to hydra?
/authorize ?
/token ?
/userinfo ?
are those even handled by hydra?
what do I have to do in my stub?
user registers - I create the user in authsrv
user confirms mail - authsrv
user logs in - ask authsrv if email/pass match
user has a profile
name
address
phone
etc..
can I just keep my model?
let's say
type Profile struct {
id string
name string
address []string
phone string
}
now my user decides he wants to create an app to display his profile on this personal website
so he creates a client_id + secret
writes the app that fetches his profile info from https://api.resourceserver.tld/profile/
I'd like the scope to be more along Google's scopes
https://developers.google.com/identity/protocols/googlescopes
not profile.read profile.write
because I have this central authserver, so I want explicitly named scopes with full URLs
Ok after I wrote all this it's a bit clearer.
Just this consent thing...
and then token generation
I mean usually some o* client just wants the user's email address and maybe the name or photo.
and local access permission could be managed with just ladon without the hydra roundtrip.
And oidc does just that, scope email profiledata
it's almost 4 am, bedtime