I am using https://github.com/agoragames/nginx-google-oauth for auth on my website. I received an email from Google saying that the plus.me scope of the Google Plus API is being deprecated. I don't see that referenced in the code. I am not sure about Libraries it may be using.
Can someone confirm this is going to continue working after the shutdown?
Looking at this line in the code, it is making its call directly to Google's OAuth endpoint, and then later making a call to Google's userinfo v2 endpoint. In neither place does it use a plus scope nor a plus API (although its claim that it's asking for "ALL" scopes looks wrong).
The Google+ API and Scope shutdown does not appear to be a problem in your case.
Today (7th March, 19) Google+ API shut down completely, I had issue in rails application with authentication and I solved it by replacing OpenIdConnect endpoint, as mentioned here
Related
So, lately I've been playing around with the Slack API and I kind of figured out how to access the API using the keys available when I use Slack in Chrome. I'm able to access the conversations.history method and download messages. Anyone with API experience know if this is a normal thing? To be able to access the API with a App or standard Authentication token (user tokens are prefixed xoxp- and bot tokens xoxb- and workspace tokens xoxa-2. The token I was using was xoxc- . ) It seems kind of insecure, so my question is, are APIs always vulnerable like this. And, also, I'm guessing that I shouldn't be accessing it like this, and wondering if anyone has heard of people getting in trouble for this or if its expected/ok?
This is the response I got from Slack regarding it.
Thanks for reaching out, I'd be happy to help.
To clarify, xoxc tokens are special tokens that are used by the web client. These tokens are cookie dependent, so even if the token is somehow stolen, it would not be very useful.
However, while we might not explicitly prevent it, using xoxc tokens for the API is not supported or recommended. Our API methods and scopes are meant to be used with Bot (xoxb) or User tokens (xoxp). Workspace tokens (xoxa) tokens are now deprecated, as they were only available to create during a limited developer preview which has since ended.
https://api.slack.com/authentication/token-types
As you continue to use the API, I'd recommend creating a Slack app and creating a properly scoped token as described here:
https://api.slack.com/authentication/basics#scopes
I hope this helps clarify, but please let me know if you have any further questions.
Currently, I am using the Token Authentication Flow to connect MS Graph OneDrive API to my application. (Link to documentation) It works, yet I have to use Postman to get a new authentication token after 30min-2h (I'm not sure about the exact timeframe). I need to be able to access the OneDrive API for a longer period of time (multiple months) without having to authenticate again and again.
In the documentation, the also speak about the Code Flow (Link to Documentation). Yet I don't receive a refresh token nor do I know how to set it up for longterm access.
I wrote an application in python that uploads files from OneDrive to another application.
Any help is appreciated!
Perhaps not a direct answer but it could help you arrive to solution via another route. In my case, I was following the process presented here, which really then lets user choose if they would like be remembered on the device. Then token gets stored and the method attempts silent authentication before requiring interactive login. So basically you get to use Graph API seamlessly.
Obviously, the authentication still needs to happen but perhaps you could reuse the token for direct requests?
I have spent the last couple of nights bashing my head against the wall amongst a see of conflicting out of date documentation and semi-helpful blog posts that were/are appropriate to what I am trying to do.
Essentially I want to write a wee personal app do download my images from PicasaWeb/Google+ and store them on my local hard disk.
I have managed to do the following:
Figured out the GData API for the appropriate request to get private album data (works fine in my 'google-logged-in' chrome browser)
Got the correct private data back from my GData URL with the token generated by the OAuth playground.
Managed to get an OAuth2 token back from https://www.googleapis.com/oauth2/v3/token using JWT.
However - when I try my access token I generate myself I get back a forbidden response with the message 'Not authorized to view access private'.
I am pretty stumped - my only guess is that my service account configured in google developers console doesn't actually have access to my personal google stuff like google+ photos. When I look in there I can see the OAuth playground has access. How do I give my app access - and do I need to in this scenario?
Thanks in advance,
Robert
"my only guess is that my service account configured in google developers console doesn't actually have access to my personal google stuff".
Totally correct.
I guess I see 2-3 questions per month on SO where people have made the false assumption that a Service Account is some kind of proxy to their Google Account. It isn't. It's a completely new and independent account.
The two approaches you can take are:-
Share the items to the Service Account so it has permission to access them.
Give your app direct access to your Picassa account. See How do I authorise an app (web or installed) without user intervention? (canonical ?) for the steps involved.
A lot of the documentation on google talks about the email scope to replace the https://www.googleapis.com/auth/userinfo.email, pared with the endpoint https://www.googleapis.com/userinfo/v2/me. Documentation found here https://developers.google.com/+/api/oauth#email.
Yet there is more documentation that states even that is being replaced in favor of the plus api and endpoint and the people.get endpoint. Documentation found here https://developers.google.com/+/api/auth-migration#email.
I have an application that needs to request the user email for both authentication and to verify they have installed our app.. A bonus is when I try to add the email scope to the developer console, or use it in my app, it tells me that email is not a valid scope.
My question is what are the proper scopes that need be applied in my app and in the google developer console? Need to be sure of this since the Google Apps Marketplace V2 has rules about prompting users.
You need to use the "email+profile" scope. That's the only way you will comply with the marketplace requirements to hide the user consent window.
Don't worry about the API console saying this is not a valid scope, it works when you provide it to the OAuth endpoint.
Here's an explanatory blog post with a sample in Java and all the required configuration steps.
Recently, AuthSub died...?
Is it possible to migration from session_token of Authsub to refresh_token of OAuth2 ?
Please tell me how to do it if possible.
Its still supported, but is failing for us as well (and others if search twitter for it). I'm wondering if Google is experience a technical issue with AuthSub or if they made a change (e.g. patch/release) earlier this week that is causing the issues?
We see it working for some Google accounts and fail for others - starting on Dec 10/11. So, its not impacting every Google account.
We are currently not capturing the outgoing requests to google. We are using the library gdata-calendar-1.0.jar to make google calendar api calls using AuthSub and the library is throwing an exception with the exception message "Unknown authorization header". This worked perfectly up until Dec 10/11th or so for all of our users.
What is strange is now the same calls do work for certain gmail accounts but not for others.
In our testing we are seeing that turning off the enhanced security in our web application results in the warning displayed to the user on the Google Authorization page but makes the connection work for the accounts that are failing.
Here are the api calls we are making:
AuthSubUtil.exchangeForSessionToken to connect to the google account
CalendarService.query to get events
CalendarService.insert to insert events in calendar
CalendarService.getFeed to get the calendars
AuthSub is still supported by Google as per Google's deprecation policy.
As for a migration path to OAuth2, currently there is none.