authorize_code without password

[aalimovs]

As per #297 (no plans for Resource Owner Password Credentials) and suggestions to use OAuth 2.0 for Native Apps, I've been trying to follow the guide:

hydra clients create \
    --id my-id \
    --is-public \
    -r code,id_token \
    -g authorization_code,refresh_token \
    -a offline,openid \
    -c https://mydomain/callback

However, hydra token user --id my-id generates a link with redirect_uri = http://localhost:4445/callback, making hydra complain

hydra_1 | time="2017-06-13T10:19:45Z" level=error msg="An error occurred" error="redirect_uri parameter does not match with registered client redirect urls: The request is missing a required parameter, includes an invalid parameter value, includes a parameter more than once, or is otherwise malformed: The request is missing a required parameter, includes an invalid parameter value, includes a parameter more than once, or is otherwise malformed"

Manually updating the link to redirect_uri = https://mydomain/callback goes through

hydra_1 | time="2017-06-13T10:21:38Z" level=info msg="completed handling request" measure#hydra.localhost.latency=87676808 method=GET remote="172.19.0.1:59596" request="/oauth2/auth?client_id=my-id&redirect_uri=https://mydomain/callback&response_type=code&scope=hydra+offline+openid&state=kyisotycjazkmpzlgssswhcz&nonce=gnqejnbophqsahncivkucxgf" status=302 text_status=Found took=87.676808ms

But then looking at logs it seems the consent fails and Hydra presents a login page.

What am I doing wrong?

[aeneasr]

However, hydra token user --id my-id generates a link with redirect_uri = http://localhost:4445/callback, making hydra complain

The CLI help command is really helpful:

$ hydra help token user

Generate an OAuth2 token using the code flow

Usage:
  hydra token user [flags]

Flags:
      --cluster string       Force a cluster url, defaults to value from config file
      --id string            Force a client id, defaults to value from config file
      --no-open              Do not open the browser window automatically
      --redirect string      Force a redirect url (default "http://localhost:4445/callback")
      --scopes stringSlice   Force scopes (default [hydra,offline,openid])
      --secret string        Force a client secret, defaults to value from config file

So this is now:

hydra token user --id my-id --redirect https://mydomain/callback

But then looking at logs it seems the consent fails and Hydra presents a login page.

Well, in order to complete the authorize code grant, you need to complete authentication and consent. In normal scenarios you implement the consent app yourself, so you have control whether or not the user needs to consent or authenticate. So I'm not sure what the issue is here, other than maybe getting a bit more into oauth2, the consent app, and the authorization step ;)

• https://www.digitalocean.com/community/tutorials/an-introduction-to-oauth-2
• https://ory.gitbooks.io/hydra/content/oauth2.html#consent-app-flow

[valichek]

@arekkas Hello, could you explain what is the difference when one creates the client with --is-public flag. Does it change the auth flow somehow? Also the error_description value that is passed to consent app is different from log message.
Consent redirect:
http://localhost:4444/oauth2/consent?error=invalid_request&error_description=The+request+is+missing+a+required+parameter%2C+includes+an+invalid+parameter+value%2C+includes+a+parameter+more+than+once%2C+or+is+otherwise+malformed
Log message: time="2017-09-12T10:02:04Z" level=error msg="An error occurred" error="redirect_uri parameter does not match with registered client redirect urls: The request is missing a required parameter, includes an invalid parameter value, includes a parameter more than once, or is otherwise malformed: The request is missing a required parameter, includes an invalid parameter value, includes a parameter more than once, or is otherwise malformed"

redirect_uri parameter does not match with registered client redirect urls is missing

[aeneasr]

@valichek the error message is equal, OAuth2 spec says that only little information should be shown to the end consumer so it's not possible to reverse engineer unauthorized requests. However, this has been a pain point for users for some time now and I'm reconsidering giving more explicit warnings

Regarding your question, the --is-public flag disables the possibility to use a secret and thus disallows the client_credentials grant. Use this flag if you have a client that runs on a user's device (e.g. SPA, mobile app).