Hey all, we've been working with hydra/oathkeeper ...
# talk-hydra
m
Hey all, we've been working with hydra/oathkeeper for about 2 years now, its been working great. We've been on a testing automation kick recently, and I'm wondering if anyone has come up with an elegant solution for programatically acquiring an access token for a user as ROPC is not supported. Allowing the passing of username and password in the original auth request query params (to be used in the login challenge) is extremely bad practise and we're not going to do that. Unfortunately Hydra does not expose an API to "generate an access token" for a user given a client_id and subject, unless it does and I've missed it.
This seems like I should be using client credentials, but the request is for a user, not a system, so would I create a client credential per user?
l
I am not from Ory, but had the same issue. Is this just a migration? Do you consider forking Hydra and adding your own grant type which would be delegated to your API to receive subject claims for the token? In this case you can do the migration with your own patch which can be thrown away after migration. Not very secure, but viable option below: You can issue your own one-time tokens which can be issued by your API in exchange for username and password (preauthentication). API would either return the token to be passed in query params or put it into the httponly cookie. Token then is used to automatically login the user. It is important tho to defer the password verification until the moment token is used for automatic login. You also have to invalidate token as soon as it is received.
m
@limited-tent-11422 I want to avoid forking Hydra. I do like your proposed one-time token, but it still requires a lot of overhead to get a token back (5 or 6 total requests including redirects).
l
Yeah, it is kinda last resort solution if you want to stay in auth code flow.
m
PCKE doesn't really help here either
@limited-tent-11422 I think I can cheat and use
client_credentials
- oathkeeper with an id_token mutator will stick the
client-id
in the
sub
of my internal ID tokens
so if i create client credentials where the
client_id
matches my user's internal identifier, it should pass through correctly.
obviously I would never want to use this in a production setting, but for automated testing it will likely work just fine