My API documentation goes in the following series.
Pre-Oauth API -> getAuthToken API -> Post-Oauth APIs
The post oauth APIs contain access token in the authorization header. Is it possible to cache the access token value in swagger and use it in that session for post oauth APIs?
Related
A newbie question about API security:
When I applied API service from some API providers, usually I just login and generate an api key or token in their api management site. After that I can embed this api key or token in the request to access the API.
I was told that the this is OAuth 2. But, after reading a few articles about OAuth 2, it seems the OAuth-2 token issued from OAuth server will expire and a refresh-token is required to fetch a new token.
But the API keys I got from those API providers does not mention about the expiration, instead, I can manually revoke the API Key on their API management site.
So, if I have some APIs which I want to use the similar way (let the user manage their own api key on my site) to protect, how can I achieve that by using the OAuth 2 server?
I think what you explained above are 2 different ways to authorize a request:
A. Using API Keys
These API keys are usually a long string that you generate inside a dashboard
You as a developer would usually have 1 API key throughout your app, and you append this API key to requests to the API provider
B. Using OAuth 2.0
OAuth 2.0 uses a different kind of token to authorize requests, it usually involves a short-lived access token and long-lived refresh token.
These tokens are usually for Users, each user will have a different token that expires every X days.
To acquire a token, the user has to "log in" to your site or an Identity Provider's site (like Google Accounts) and enter their credentials every time the token expires.
Here's a picture to show the difference:
If you want to provide an API service for other developers:
Use OAuth 2.0 to log in the developers to their dashboard (this means your server routes that interact with the dashboard would be protected by the OAuth 2.0 tokens, requiring the developer to log in to update some settings)
Use API Keys to access your provided API routes. Developers have to log in and generate API keys from the dashboard. Then they can use this API key to fetch resources from your API.
Here's a more thorough explanation about OAuth 2.0, access tokens, and how to implement it on your site.
I just want to fetch some data from the playlist, to make it work. Which Credentials do I need to use?
API keys
OAuth 2.0 client ID
If you are just getting playlist, searching YouTube videos via keyword or listing videos you can use API keys, but if you have to upload videos or access private user data you have to use OAuth 2.0 client ID.
OAuth 2.0: Your application must send an OAuth 2.0 token with any request that accesses private user data. Your application sends a client ID and, possibly, a client secret to obtain a token. You can generate OAuth 2.0 credentials for web applications, service accounts, or installed applications.
See the Creating OAuth 2.0 credentials section for more information.
API keys: A request that does not provide an OAuth 2.0 token must send an API key. The key identifies your project and provides API access, quota, and reports.
See the Creating API Keys section for information about creating an API key.
Hope this helps.
I am looking for concrete information regarding the state of RFC7636 (proof key for OAuth token exchanges) in Google's OAuth2 APIs.
Google exposes an OAuth 2.0 and OIDC provider API where access tokens can be obtained. There is a proposed standard described in RFC7636 for using proof keys in token exchanges which we have started using in our integrations with major identity providers. Some accept the proof key, others ignore it; Google seems to be aware of it but fails to validate the proof key. I have not been able to find any mention of this wrt Google.
In concrete terms, when following the authorization code flow of OAuth 2.0 with Google as the provider we generate a random number, hash it using SHA256, base64 URL encode it, and then pass it to https://accounts.google.com/o/oauth2/v2/auth as parameter "code_challenge" and "code_challenge_method" as per the spec.
The endpoint accepts the parameters and issues an authorization token as usual. When obtaining the access token we call https://www.googleapis.com/oauth2/v4/token with the code_verifier; the endpoint returns the following HTTP 400 error which suggests that there is some awareness of code verifiers:
{
"error": "invalid_grant",
"error_description": "Missing code verifier."
}
Google's OAuth documentation at developers.google.com/identity/protocols/OAuth2 does not mention any of these parameters; the API playground does not extend to playing with the OAuth2 auth and token endpoints. Any insight would be greatly appreciated.
I was having this same problem using AppAuth and an Android clientId. In order to fix it I had to set a matching 'code_verifier' field on both the authorization and token requests. You can find a more in depth description in this post: invalid_grant trying to get oAuth token from google
We are exploring the MailChimp API v3.0. There are two types of authentication methods: Basic and OAuth 2.
We are able to authenticate using both ways, but there is confusion with the Authorization Header part:
Basic Authentication (both authorization headers below work):
Authorization: Basic base64 format of username:APIkey
Authorization: Basic only APIKey
OAuth 2 Authentication (both authorization headers below work):
Authorization: OAuth access_token
Authorization: OAuth only APIKey
The API documentation refers only to the first approach of each of the above authentication methods.
Is the second approach of each valid? i.e. can we authenticate using only the API key in the place of the base64 encoded string (Basic auth), and only the API key in place of the access token (OAuth 2)?
OAuth on MailChimp is a way to retrieve an access token. You can then use that access token (or an API Key that you get from the dashboard) in the Basic Auth setup.
While it may work to pass the API key by itself in the header, I'd recommend following the actual Basic Auth methodology of the base64 encoded 'username:apikey' or 'username:access_token'. Almost all HTTP libraries will do this part for you. For example, with cURL, you can do this:
curl --user myusername:myapikey "https://dev.api.mailchimp.com/3.0/lists/"
Depending on your language and library, it will be handled different ways, but all of the ones I've worked with have made it easy to do Basic Auth.
I want to integrate my application with ServiceNow using its REST API. For this, my app needs to get authorized using OAuth 2. I have searched for Authorization and Token endpoints in the wiki of ServiceNow, but could not find any.
Can anyone please post here those urls?
Starting with the Fuji release ServiceNow supports authenticating to REST endpoints using OAuth. First off, be sure to enable the OAuth plugin if it's not already enabled on the ServiceNow instance you are trying to integrate with. For information on how to do this and how to setup an OAuth endpoint check out these product docs.
Setting up OAuth
ServiceNow OAuth with REST
Generating OAuth tokens
Once you've created an OAuth endpoint in the application registry on your ServiceNow instance you'll need to generate tokens to use for authentication. You can find curl samples for generating tokens in the product docs. Review the response to the request you made to generate tokens and grab the 'access token'. The response from generating tokens should contain a JSON body similar to the following:
{"scope":"useraccount","token_type":"Bearer","expires_in":1800,"refresh_token":"w599voG89897rGVDmdp12WA681r9E5948c1CJTPi8g4HGc4NWaz62k6k1K0FMxHW40H8yOO3Hoe","access_token":"F0jh9korTyzd9kaZqZ0SzjKZuS3ut0i4P46Lc52m2JYHiLIcqzFAumpyxshU9mMQ13gJHtxD2fy"}
From the response you will want to record the 'access_token' and include it as a bearer token in subsequent requests to the ServiceNow REST API endpoints.
Sample request to REST Table API using the access token:
curl -H "Accept:application/json" -H "Authorization:Bearer 2wRlsRCT2SYjCCJP91kwo2EFzj5qg4O3I3aC09e0-0hz6Ib3YK7If-LMiNorNuglfqbkL4AfkYC92KYHUCcbpQ" "http://<instance>.service-now.com/api/now/table/incident"
Hope that helps!
It seems ServiceNow supports only password and refresh_token grant types. Please see here. Authorization and Token urls are for Authorization code grant type.