I have succesfully used the shared keyrock from filab to let my on web application to authentificate users, using oauth.
When I tried it with a second application, I get an error from FILAB web page: "Bad Request"
The error occurs after the users logs in.
Is there a way to get additional information, what was wrong with the request?
I'm guessing you are using the "authorization code grant" flow defined by the OAuth2 standard and supported by Keyrock. In that scenario, you need to provide three parameters when building the authentication URL:
response_type must be code (or token when using the "implicit grant" flow), otherwise IdM will return an unsupported_response_type error.
If the client_id exists, but the redirect_url doesn't match the one provided when creating the application, then a bad request error will be raised. This error can be raised if the client_id is wrong, if the redirect_url is wrong or if both are wrong. This is your case.
If the client_id app doesn't exist, the IdM will return a 404 error page.
If any of these parameters are missing in the request, the IdM will raise an invalid_request error.
Except for the error 404, Keyrock seems to follow the OAuth2 protocol.
Related
I'm stuck with an issue while trying to use Google's OAuth2 php lib. On the server side, after I instantiate an OAuth2 object I redirect the user to Google's sign in page, after which they hopefully grant permissions based on the scopes (the APIs I declared for use in the OAuth2) I declared. Now here's my issue: after the user grants permission I get redirected to the redirectUri I specified during the instantiation of OAuth2. This redirectUri contains as params state, code, and scope k-v pairs. I always get a "Missing authorization code" if I don't send back the value code to server and set it as a property of the OAuth2 object. However, if I send back the value of code to the server and set it as a property of the OAuth2 object I get a
"Client error: POST https://www.googleapis.com/oauth2/v4/token
resulted in a 400 bad request response. Error: "invalid_grant"`
So, I'm at lost here. I should mention that I actually managed to make 2 authorized calls to Google Ad Manager (the scope I declared) using the same flow I described above, but after that I keep getting the same 2 errors as above.
Does anybody know what's going on? I must be missing something but I can't see what. I'm using this guide so it's not really convoluted or complicated code but I just can't get it to work somehow. https://github.com/googleads/googleads-php-lib/wiki/API-access-on-behalf-of-your-clients-(web-flow)
Trying to set up an Authentication for my app, and all seemed to be working correctly, but when I tried testing it out I got this error message
Authorization Error
Error 400: redirect_uri_mismatch
The redirect URI in the request, http://localhost:3000/api/auth/callback/google, does not match the ones authorized for the OAuth client. To update the authorized redirect URIs, visit: https://console.developers.google.com/apis/credentials/oauthclient/${your_client_id}?project=${your_project_number}
Can you point me in the right direction to fixing this?
Error 400: redirect_uri_mismatch
Is a configuration issue. The redirect uri is used to return the authorization code to your application after the user has consented to your applications access to your data. You have created a web client credentials up on Google developer console.
What you need to do is go back there and add a Redirect uri of
http://localhost:3000/api/auth/callback/google
It must match exactly don't add any spaces at the end or anything.
If you have any issues i have a video which will show you exactly how to add it Google OAuth2: How the fix redirect_uri_mismatch error. Part 2 server sided web applications.
Seems like there's a mismatch with the Authorized redirect URIs. Are you sure you have entered the correct URIs? Redirect URI should be the URL that you'll be redirecting the user to after the login page or the base URL of your application Eg: https://localhost:8000
Also, make sure that you are using the correct Client ID and Client secret
Similar Questions
Google OAuth 2 authorization - Error: redirect_uri_mismatch
Correct redirect URI for Google API and OAuth 2.0
I'm integrating to Google OpenID Connect as a relying party, using the authorization code flow. If I send in an invalid parameter in the AuthenticationRequest, e.g. an invalid value for scope, Google presents the error in a web page saying e.g. "Some requested scopes were invalid...".
The OpenID Connect spec (and the OAuth spec) clearly states that: "Unless the Redirection URI is invalid, the Authorization Server returns the Client to the Redirection URI specified in the Authorization Request with the appropriate error and state parameters."
Am I doing something wrong in my request, or am I misinterpreting the specification, or are Google just not conformant when it comes to sending error responses?
Sounds to me like Google is a little non-conformant here:
Step 10 of my blog post shows the standards based behaviour
As a developer of an OIDC client you need to accept that some invalid input will be displayed in the browser:
Invalid client_id / redirect_uri
I tend to use an invalid scope to test error responses - it is handy for that - and I guess you're doing the same.
Solutions from the big cloud vendors often have this type of annoyance - when all that we want as consumers is a standards based solution.
When going through Epic's App Orchard Oauth flow , any misconfiguration of the app results in an error which says "INVALID_CLIENID".
One issue is that error text is confusing because it isn't the clientId that is incorrect for some other config parameters (could be an incorrect redirect_uri for example).
Another issue is that such error response comes back with status code 200 - indicating successful request.
Is there a way to get an error code indicating a failed request ? Some code in the 4xx range
For INVALID-CLIENT-ID, in the current version of the software you just need to check all of the different causes.
Common causes of the INVALID-CLIENT-ID error include:
Providing an actual invalid client ID.
Providing a redirect_uri that isn't associated with your client.
Performing a FHIR interaction (read/search) on a resource that isn't listed in the FHIR API Scope for your client.
From RFC 6749 section 4.2.2.1:
If the resource owner denies the access request or if the request fails for reasons other than a missing or invalid redirection URI, the authorization server informs the client by adding the following parameters to the fragment component of the redirection URI
From RFC 6749 section 4.1.2.1:
If the resource owner denies the access request or if the request fails for reasons other than a missing or invalid redirection URI, the authorization server informs the client by adding the following parameters to the query component of the redirection URI
The former applies to Implicit Grant flow requests to the Authorization Endpoint; the latter applies to Authorization Code flow requests to the Authorization Endpoint. The difference is indicated by the response_type parameter the client sends to the Authorization Endpoint; token indicates Implicit flow, and code indicates Authorization Code flow. Therefore, if an error occurs, the logic is as follows:
if response_type == 'token'
error response in fragment
else if response_type == 'code'
error response in query string
else
????????????????????
end
The spec appears to leave it open what to do in the final "else". A possible client error would be to include a response_type parameter with a value other than code or token. This may not meet the criteria for an un-redirectable error, so an authorization server should redirect to the redirect_uri if possible with a suitable error response (error=invalid_request or possibly error=unsupported_response_type).
But where does that error parameter go? Query component or fragment? Both? Should this after all be treated as a non-redirectable error like an invalid redirect_uri?
Reading RFC 6749 carefully, it can be found that a client can access the authorization endpoint without having registered its redirect URI(s) in advance if some conditions meet. The conditions are (1) confidential, (2) implicit and (3) explicit redirect_uri parameter. In this case, response_type needs to be determined before redirect_uri is determined. This means that there is a case where unsupported_response_type error cannot be reported to the client by redirect. So, we don't always have to report unsupported_response_type error by redirect (because we cannot do it in this case).
If I were you, I would just send "400 Bad Request" to the client with an error message. IMHO, clients that cannot specify even response_type correctly are unqualified to receive responses via redirect and should be notified earlier of such a basic error during their early development phases.