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.
Related
We want to make simple authorization for server-server HTTPS communication (we control both servers) like classic API_KEY: client has hardcoded (in a config) a key which use in every request. Server check if the key is valid.
Our colleague has implemented it like OAuth2 Bearer token (RFC6750)
Authorization: Bearer client_key
So the client has the client_key in the config, it's never refreshed. It works well, we have just a philosophical dispute in the company, if such "hardcoded" Bearer token is along with OAuth2 or not. (Disclaimer: I am not with any side of the dispute.)
The OAuth 2.0 protocol basically defines an access_token - which is a token that is bound in time and permissions - and two protocol "legs":
how to obtain and access token
how to use/present an access token
You do not use access tokens (since your tokens are not bound in any way) and you've only "syntactically" implemented part 2. In fact you don't actually implement OAuth 2.0 in that case. You may present the client_key just as well in an HTTP Basic header or in a query parameter, it has nothing to do with OAuth 2.0 except that you're borrowing (arguably: abusing...) its header name and format.
How to configure postman when you already have a token/bearer key at hand?
Was hoping it would be somewhat similar with seting up an OAuth2.0 authentication with SoapUI that you can just input the bearer/token key.
If you have an access token, you can configure POSTman by setting up a custom Authorization header. Setup:
Authorization: Bearer <accessToken>
And if the API you are accessing supports bearer tokens, and you are providing a valid access token, then it should work.
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
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.
In OAuth 1.0, 2-legged is pretty easily: Simply send the request as usual and omit the access_token header.
Things seems to have changed in OAuth 2.0 (drastically, as I found out today :)). In OAuth 2.0, the request no longer has headers such as the nonce, consumer key, timestamp etc. This is just replaced by:
Authorization: OAuth ya29.4fgasdfafasdfdsaf3waffghfhfgh
I understand how 3 legged authorizations work in OAuth 2.0 and the application flows. But how does 2-legged work in 2.0? Is it possible to design an API that can support both 2-legged and 3-legged OAuth 2.0?
I have been searching for information regarding this, but I have been finding a lot of stuff on 2-legged for 1.0 and almost nothing for 2.0.
After lots of research, I discovered that client_credentials grant type is for this scenario. Once you punch this term into google, you can find loads of very helpful resources.
This is the normal flow for 3-legged OAuth 2.0 (we want the user to sign in):
Assume we have the following endpoints in our app for authentication:
/oauth/auth
/oauth/token
Normally (for authorization code grant), we direct the user to /oauth/auth?state=blah&client_id=myid&redirecturl=mysite.com/blah
Then upon authentication, the user is redirected to mysite.com/blah?code=somecode
We then get somecode and exchange it for a token using /oauth/token?code=somecode&client_id=myid&client_secret=mysecret
We can then use the token to make calls.
This is the application flow for client_credentials to implement 2-legged OAuth 2.0, which is markedly simplier:
In this approach, we do not need to perform any authentication.
We simply POST to /oauth/token with the following form data:
grant_type=client_credentials&scope=view_friends
Note that scope is optional. The endpoint then directly returns an access token for us to use (no refresh token is provided). Since no refresh token is provided, when the token expires, you will need to reauthenticate and ask for a new one.
This leads to the following caveats:
Use this only for (very very) trusted applications such as internal applications.
You need to devise your own way to authenticate. For instance, the RFC's example uses basic auth.
Another solution is to use JWT (JSON web tokens) like the google OAuth API. It is a very complicated process, but there exists numerous libraries for generating your JWT. You then post the following form data (url encoded of course):
grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer&assertion=generated_jwt
This is posted to /oauth/token to get your token.
As for the question of whether you can create an API that supports 2-legged and 3-legged OAuth 2.0, Yes, it is possible.
Then /auth endpoint is only used when users need to authenticate against the service.
In the /token endpoint, simply check the value of grant_type in the GET parameters for urn:ietf:params:oauth:grant-type:jwt-bearer if using JWT or client_credentials for client_credentials.
Note that when generating the client_id and client_secret to give to the user, if you are supporting multiple grant_types, ensure that you have a database column to store what type of grant type the id and secret was generated for. If required to have multiple grant types per user, generate a different set of credentials for each grant type.
You can also check out Google's implementation of 2-legged OAuth2 (I believe this documentation has been published only recently).
The Google Drive SDK delegation docs should also help understanding Google's 2-legged OAuth2 implementation.