I am using Auth0 Management API, so I assume that it gives consent automatically for my users from my app.
{
"date": "2017-06-22T19:25:25.198Z",
"type": "fsa",
"description": "Consent required",
"client_id": "KGo7Zr98BNJlFjgquRNM4vziGmpg7jfx",
"ip": "189.6.84.54",
"user_agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.36",
"details": {
"body": {},
"qs": {
"client_id": "KGo7Zr98BNJlFjgquRNM4vziGmpg7jfx",
"response_type": "token",
"redirect_uri": "http://remoto-dev.remoto.me:4200/silent-callback.html",
"scope": "openid profile offline_access",
"audience": "https://remoto-dev.auth0.com/api/v2/",
"prompt": "none",
"response_mode": "fragment",
"state": "dcXZzf8io85j9eO4jq_yT2kV.yaJI-gr",
"auth0Client": "eyJuYW1lIjoiYXV0aDAuanMiLCJ2ZXJzaW9uIjoiOC42LjEifQ=="
},
"connection": null,
"error": {
"message": "Consent required",
"oauthError": "consent_required",
"type": "oauth-authorization"
},
"session_connection": "sms"
},
"user_id": "sms|58e3e280879f18288a985deb",
"user_name": "charlie@test.com",
"log_id": "49574347664067592668682871112839985273660246360162566178"
}
I read an answer from @abhishek.hingnikar and thought the reason could be the fact that it was not giving consent to localhost, so I tried to change that by editing my /etc/hosts where I point 127.0.0.1 to dev.mydomain.com, but it didn’t work. Same error.
The resource server associated with the Management API requires explicit consent from the end-user when performing an authorization request; to my knowledge this is not configurable, so the silent authentication will only succeed after the user has provided consent in an interactive authentication flow. This means that the error in question is unavoidable unless you first use an interactive flow that would allow the user to authenticate and provide consent.
Additionally, have in mind that most of the scopes associated with the Management API won’t be available to be provided in access token issued as part of an end-user flow. At most end-users would be able to request scopes that are associated to their current user.
In general, if you want to provide certain operation that can be triggered by end-users and that require Management API requests you would broker this access in your back-end and/or API and do not request Management API access tokens directly from an end-user flow. Instead you would use client credentials; see the reference documentation for additional information on this.
@jmangelo The only reason I have defined Management APi as the audience was to try to make silent authentication work, I just followed documentation. I actually don’t even like the idea of granting access to end users to this API, when my only need is to let the user be authenticated without a prompt. I thought it was a requirement for renewAuth.
1 Like
I am confused by "…so the silent authentication will only succeed after the user has provided consent in an interactive authentication flow. ", as conflicts with this answer: “The default Auth0 consent … does not happen for first-party clients as in general these applications will be associated with the user identity itself and it would not make sense to display the consent screen by default.” We are first-party in this case.
So, here are the questions in my mind:
- Is silent auth impossible when using Auth0 as the authentication provider (not social) and when you don’t want the user to be prompted by auth0 page in any flow?
- Is silent auth possible in case stated #1, but the problem was the use of “management api”?
- If #2 is true, what should be the audience?
- Or in the case stated #1, silent auth is possible, but we neeed to to implement something server side?
As you see, @jmangelo, I am pretty confused
That answer then goes on to explain when consent may also be requested for first-party clients; which happens when the API explicitly requests that and the Management API happens to also request it as I mentioned before.
You can use renewAuth
without providing an audience; including an audience has the side-effect of making the request be treated in strict conformance to OpenID Connect even if the client application has not enabled OIDC Conformance through the client settings. This allows the client application to selectively choose to perform some requests according to OIDC which may or may not be interesting to you. If it is, you can provide an audience of https://[your_account].auth0.com/userinfo
. This audience is almost a NOOP as it does not trigger consent.
This solves. I don’t understand why was management api in the audience in the documentation. Thanks.
1 Like
Answer is in @jmangelo comment. One can use https://[your_account].auth0.com/userinfo
as audience and prevent this problem.
I keep getting this error even after I’ve successfully logged in through the entire authentication flow, including the consent screen. I’m passing the exact same auth params to auth0.webAuth
and auth0.checkSession
. Also, is there an easy way to test whether silent auth is working properly? Right now I have to wait 2 hours for it to expire before it throws the error.
I keep getting this error even after I’ve successfully logged in through the entire authentication flow, including the consent screen. I’m passing the exact same auth params to auth0.webAuth
and auth0.checkSession
. Also, is there an easy way to test whether silent auth is working properly? Right now I have to wait 2 hours for it to expire before it throws the error.
1 Like
Actually nevermind, I think I have a problem where I’m testing two different email accounts and the first session is authorized with the same user_id as the second session. I’ll need to dive into this further.