I've been using the plus.people.get Google method with an OAuth2 bearer token in order to fetch the user's email address after an OAuth2 login. That endpoint will be shut down in March, with 'intermittent errors' starting at the end of January.
I can't seem to find an equivalent endpoint that allows me to exchange an OAuth2 token for the user's email address with no, or minimal, additional scope. All the (numerous) answers I've come across on SO are out of date due to the deprecation, there's no replacement APIs listed in the shutdown announcement, and so far I've not found a functionally equivalent Google API.
The Gmail profile API will allow email retrieval, but the minimal scope allows reading the user's email. I don't want to require my users to have to approve that for obvious reasons.
Sorry if this is a duplicate, but I'm unable to find anything helpful so far.
EDIT: of course directly after posting I found the people API.
Authorize the scope https://www.googleapis.com/auth/userinfo.email and call the Google OAuth2 API endpoint (oauth2 v2) userinfo.v2.me.get if you are using a library or directly to https://www.googleapis.com/userinfo/v2/me with the authentication.
Related
I'm currently having users login to my site using Auth0's redirect functionality. It's great, but my past experince with google's oAuth tells me there's a problem. With my other site, we do the same login, the user gets a JWT and posts that to my API server. My API server then takes that token and contacts google to ensure this is actually a token that they made. And THEN, I give them a Bearer code that they can use for when they want to access the database.
With Auth0, I can't seem to find any way to contact them from my API server and say, "Hey, someone sent me this token, it checks out that it isn't corrupted, is for a data that is in the future and it says you are the issuer and it has the proper Auth0 client id. So, did you issue this?"
I must be missing something.
Thanks everyone.
Our APIs (delivered by a third party) are using Tokens in order to ensure authorized access only. Our new website should not be server-to-server but mostly front end, i.e. the token would be visible in the script. We're now checking how to secure the API for a frontend website and I have to propose ways to my boss. However, I've never had to do something with API securing, could you please help me by telling me where to read / state of the art solutions?
I've already begun to look into OAuth1a, OAuth2, OpenID but can't (yet) really get a direction to further investigate.
You should still use a token, but you have to make sure that the token doesn't grant you full access to the API.
Tokens need to be specific to the user who's using the application, and the token can only grant API access to the specific functions that the user is allowed to do.
For now I would ignore OAuth1 and OpenID and only look at OAuth2. There's enough features there to do what you want, and it's simpler than the rest.
So I want to understand a little more about authentication in an API. I know very little about how security works.
I am using Auth0 for my app and it supports only logging in from a social media site. My API checks if a user is authenticated and checks data that is being sent to avoid wrong stuff to be saved in the database(mongodb). That is all I have currently implemented to secure my API. Is it possible that a user can take his own token that he got from logging in and post information to a different account by simply guessing a different user _id.
For example, an article receives all its content and the id of the article author.
If this is possible what are some solutions on securing my API.
Any other tips on making an API secure are appreciated!
Auth0 supports logins with anything , not just social networks. You can login with username/passwords, LDAP servers, SAML servers, etc.
A token is a secure artifact. An author cannot change the id in a token without compromising the token itself (e.g. the digital signature will fail), so impersonating someone else is not that easy. The very first thing your API would need to do is checking the integrity of the token being added to the request, and reject any that contains an invalid one (bad signature, expired, etc).
It is a question that requires a lot of content, so I would recommend starting here: https://auth0.com/docs/api-auth
Primary question:
Is there any (supported/non-hacky) way to use Quickbooks Online and Customer Account Data APIs without involving a browser at all, i.e. making an API request from a server?
Commentary:
The IPP docs only mention saml and 3-legged oauth, which seems to imply that any authentication and subsequent api calls must come from a browser.
Note that this is not satisfactorily answered by this:
How can I use API to get quickbooks data without browser based OAUTH?
, as that answer:
is not by Intuit and does not point to an Intuit source
suggests a hacky solution: a user/browser authenticates, after which the oauth/etc. credentials are stored and reused. This seems like a particularly bad idea for long-term use unless explicitly approved by Intuit, due to the fact that the apis may (and probably will) expire any oauth/saml tokens at some point.
No, to get accessToken and accessSecret you need to use a browser.
As you have mentioned, your 2nd option is the only way to achieve this. i.e reusing stored tokens.
PN - OAuth tokens are valid for 180 days. Before the token expires, your app can obtain a new token to provide uninterrupted service by calling the Reconnect API. You can automate this part by writing a small program which will call ReconnectAPI when tokens are older than 150 days.
Ref - Manage OAuth Tokens
You can generate OAuth tokens(for the very first time) from here - IPP OAuth Playground
CAD
Here, OAuth tokens are valid for 1 hour. After an hour, your application will have to issue another SAML assertion again to request a new OAuth token to use. The token should only be persisted during your user's session, and then destroyed.
Ref - CAD SAML
Thanks
I want to add PayPal REST API capabilities to our shop software. Unfortunately it seems there is no way to automate to process of connecting the merchants account to our system. It looks like if you use the REST API you need to ask for client ID and secret. Then you trade that information for an OAuth token. However this is not the normal OAuth flow, which has a step that asks for users permission and does not require credentials to begin with.
These two topics basically cover the same issue, but are rather stale:
paypal rest api credential via oauth
Is it possible to use `Log In with PayPal` to make REST api requests on behalf of the user?
Does anybody know if this is possible in the meantime? I find it rather strange to design a RESTful API with OAuth capabilities and then not using it by allowing people to automatically ask for access rights on behalf of the merchant? This makes is somewhat useless for all shop software doesn't it? Well at least inconvenient.
Or is there maybe a way one could use the old API to obtain an access token that can also be used with the REST API?
Have you looked into the Permissions API?