I'm setting up an OAuth login flow.
https://accounts.google.com/o/oauth2/auth first told me the client was deleted - which is fine - I created a new one.
Now, accounts.google returns 400 redirect_uri_mismatch (which is true if you count a trailing '?' that doesn't exist in the new client settings.
Additionally, the error page displays the OLD client project name.
It may be a propagation issue, but if anyone else has seen this behaviour, I'd like to know.
PS the target user is a GFW account.
Turns out the user was still attached to the old/deleted client, although that client had been deleted. The old and new client shared a Google API project.
Related
I'm unclear about how OAuth2 (or at least google's implementation of it) works for server applications as far as redirect_url is concerned.
I'm trying to achieve three use cases:
Case 1:
A user who has never logged in logs in through my web interface using the well-documented tools found in the google identity management API, which produces a token.
My javascript client sends the resulting token along with username (or anything else needed) to the server.
The server uses the token and additional information to make sure the user is authenticated and has access to some resource that is requested, for instance basic login.
Case 2:
A user has already logged via web page and their token is available as a cookie that has not expired, and the initial page forwards that to the same token checking mechanism as above.
The server uses the token to validate their session.
Case 3:
A user is accessing my server from an app (like Unity or some other compiled Qt application or even on a command line) and is prompted for credentials because no token can/should exist when cookies aren't a thing in this context.
If their credentials are no good, the application says so, and asks for new ones.
If the credentials are good, a token is generated but is probably not used except if the token needs to be refreshed at some time interval, because we assume that re-running the app or command line is effectively a new session.
None one of these cases requires my server to use the redirect_url (except maybe the case of #2 where the token is expired), because:
Case 1, the user would have been unable to pass a token in the first place if they can't log in, and would have been redirected before that.
Case 2, the server accepts the token and doesn't redirect, or rejects the token and only then may redirect them back to the initial state of Case 1, but the server already wants to redirect them because the token is invalid, so I don't need/want the redirect_url from oauth.
Case 3, we are assuming there is no browser and don't care about redirect_url in any case no matter what.
As my code works now, using: https://developers.google.com/identity/protocols/oauth2/web-server there is always this redirect_url field which I don't know what to do with, and when I execute REST commands I'm getting raw html back which includes self-submitting javascript instead of useful headers.
I can see a case for exposing some URL on my server to validate an oauth2 session/token from google during authentication, for instance, but that would be a validation url, not a redirect_url, because the user/server doesn't "go" to that url at that point in the process.
So, I don't know what to do with redirect_url because when I leave it out, things don't seem to work.
There's a lot going on in this question, so I don't really know the type of answer you're looking for. I wrote our code for authenticating our Qt app with Google SSO, and wrote the linked post discussing the problems we faced.
One thing I found confusing in the documentation and provided examples is that when defining an app in the Google console, if your client is a desktop one, there's no field for redirection URLs. Instead, the client specifies it when initiating the authentication flow, and then it's expected to open a transient server that listens for the return connection from the Google side. There's no point declaring it on the Google console because it cannot be validated unless the client app is running at the moment, and even then, it's typically a hardcoded URL like http://127.0.0.1:1234/ as you would expect.
I have been happily using the xoauth client to negotiate PKCE grants flows up to earlier today.
Tokens were obtained and refreshed, all was looking fine until I needed to amend my scopes and needed to re-consent.
Now I receive an error on the callback - http://localhost:8080/callback?error=access_denied&state=8AJEDHk6tlNX2E98Y3JuFmXmDrcS2DNB#_=_
This error would usually indicated that consent was canceled by the user but I am definitely pressing Allow.
I have:
Deleted the app and made a new one, tried a new Code Flow app, tried a trial organisation instead of the Demo organisation, all without luck.
However, it will succeed if I specify the bare minimum of scopes: openid and offline_access
Any ideas?
My Client ID is: 17B89D9AF3984680BCA620A3986AE8EB
Update: It does however work in a private browser window so I suspect something local. Will poke some more and close if so.
So that last piece makes it sound like some kind of browser / cache issue.
We did have another user where an ad blocker was causing the problem during the granting access page. Maybe that was you..? API team is looking into this further.
If you are continued to be blocked you can open a ticket by emailing api#xero.com
I have a couple of different apps hosted on netlify using google APIs that have broken now because netlify changed their hosting to point to xxx.netlify.app instead of xxx.netlify.com
When I attempt to add the new domain to my oauth client IDs under "Credentials" I get an infinitely hanging wheel of death when I click "save"
I thought that wheel of death is caused by the new URL not being registered for the app, so I went to the settings for my application and tried to add the new domain, but it is failing as well.
I go to OAuth Consent Screen -> Edit App which then has another list of "authorized domain."
In the list, I see my old domain name:
foo.netlify.com
I try to add the new name:
foo.netlify.app
However, that auto-corrects to just plain netlify.app
I try saving that and get the following inscrutable error
Error
The request failed because one of the field of the resource is
invalid.
Tracking Number: c4522674593257747
I don't see any way to read more about the error or to use the tracking number to find out more information.
Any troubleshooting pointers would be appreciated. I'd rather not start over from scratch, but at this point it looks like my best bet would be creating a whole new application and starting the whole credential/API Key process over for all of my apps that were hosted on netlify.
I got the same problem and posted it in the google group. I have a reply from google cloud support which states that only top private domain is allowed as stated here Setting Up OAuth2.0
As the error clearly denotes and explained in this document, you can use any Top Private Domain as an Authorized Domain. So it seems to be the intended behavior.
I suppose that means only the domain owner can get a credential now.
I have an app that already successfully uses google oauth, but now I am trying to setup a staging deployment. It is a rails app with devise and omniauth, but I think there might be a problem with how I configured Google.
In the google api admin panel (https://code.google.com/apis/console) I can see the existing app. I created another one with a different callback url (because it is staging). Using Postman (a fancy way to edit the url parameters) I can send a get request to google with the current production client_id and redirect_url and it works fine. When I copy and paste in the new clients (staging's) client_id and redirect_url I always get the error Error: invalid_client.
I'm sure where to start with trying to the figure out the problem, but I've tried a lot of different steps, renaming the urls, changing the client secret, or recreating the client in the admin panel. Any ideas? This error is rather cryptic.
We had a temporary issue with a small set of client ids. The issue should be resolved. If you are still having problems please follow up.
I'm trying to write a new application using the Flattr REST-API version 1 (not the beta v2). The application acquires a request token at first, which seems to work properly. But I run into a problem authenticating the user. The link created for authentication looks like this:
https://api.flattr.com/oauth/authenticate?access_scope=read,click&oauth_token=MY_REQUEST_TOKEN
Clicking the link everything seems alright. Information about the application and the scope requested is shown, but clicking "Authenticate", there's no pin code, but the following error from https://flattr.com/apps/pincode/MY_REQUEST_TOKEN:
Something went wrong. Please try again
BUT now the Application IS in the authorized application list of the user though that doesn't really help if the user can't get the pin code...
The Application type is set to client. It's the first time I try to work with the API so I'm not sure if I miss anything important? Would be grateful for some help.
Just as an update: We finally changed to API v2. Getting Authorization for our application feels a bit clumsy, as we set the redirecturi to some webpage, where we display the returned code and let the user copy&paste it into our client application... we kind of made our own pincode-flow :/
If possible, please use the v2 api, which uses oauth2 + bearer token.
However, the new API doesn't support authentication using the pincode flow.
As stated by Maike this is probably a bug that has surfaced yet again :(
I'll create an internal bug ticket and try to get it fixed.
The pincode isn't a feature planned. You can use the oauth2 "implicit grant" to authenticate the resources owner. This isn't documented at the moment but is possible.
When you do the request to https://flattr.com/oauth/authorize you pass the response_type token instead of code. This will append a access_token fragment in your callback URL. In your http client it might be possible to catch the 302 from our server and parse the access_token from the fragment.
All this requires a http client in your application whom you can control the flow inside your app.