We are using Apigee Platform to host our api's. Our Api Proxy in Apigee is configured to use Oauth 2.0 client_credentials and implicit grant types.
We are creating Console To Go to provide testing console for our API's to developers and Configured the console to use Oauth 2.0 Implicit Grant Flow.
When we test the actual calls, we always get 401 from Apigee. Here is the response
HTTP/1.1 401 API is secure. Needs security Credentials
WWW-Authenticate:
Bearer realm="null",error='invalid_token",error_description='oauth.v2.InvalidAccessToken: Invalid access token"
Content-Length:101
Content-Type:application/json
{
"fault": {
"faultstring": "Invalid access token",
"detail": {
"errorcode": "oauth.v2.InvalidAccessToken"
}
}
}
Actual Request that was sent to our API was:
GET /whodini/v1/discovery?email=puneet%40whodini.com HTTP/1.1
Authorization: OAuth M********N (Masked for security)
Host: whodiniinc-test.apigee.net
X-Target-URI: http://whodiniinc-test.apigee.net
Connection:
Keep-Alive
ValidateAccessToken policy of Apigee looks for token value in Authorization: Bearer {token} header and my suspicion is it fails with 401 because actual request made by Console to go contains Authorization: Oauth {token}.
Is there any way to
1. Control Authorization header value while using Oauth Implicit Grant Flow so that while making API calls Console to go uses Authorization: Bearer M********N instead of Authorization: OAuth M********N
Add a rule in the ValidateAccessToken policy of Apigee Proxy to that it interprets Authorization: OAuth M********N (Masked for security)
Please follow the below steps to resolve your issue:
Go to https://apigee.com/togo
Login
Select OAuth 2.0 Implicit Grant Flow (User Agent)
Select 'Draft Version' as '14 or later'
Click 'Save Credentials' button
Hope this helps. Please let me know if you have any further questions.
Thanks,
Archendra
Related
I am currently working with a group of applications that are running on two separate, but equivalent, environments (Referred to as ENV1 and ENV2). I have been using OAuth 2.0 for Authorization and when I receive a response after requesting an access token from the OAuth service (I am making my requests through Postman) I get a response that looks like this from ENV1 and ENV2:
As far as I am aware, I believe that this "token_type": "Bearer" means that when I send in the access_token to my application I need to do so like this:
By sending in the token through the Authorization header, prefixed with "Bearer". This approach works fine on ENV1 but on ENV2 the request fails unless I send in the token alone with no "Bearer" prefix:
If I send in the Authorization header with the "Bearer" prefix, I get a 401 Unauthorized error as the response. This is the help tip that Postman provides(Emphasis mine):
Similar to 403 Forbidden, but specifically for use when authentication is possible but has failed or not yet been provided. The response must include a WWW-Authenticate header field containing a challenge applicable to the requested resource.
The problem here is that there IS a WWW-Authenticate header field, and it contains "Bearer", which I would assume is a "challenge applicable to the requested resource" seeing as the token response contained "token_type": "Bearer":
Questions:
Why would this be different between environments?
How is this even possible? The documentation I have found on OAuth 2.0 shows that the "Bearer" prefix is needed for requests like the ones I am trying to make. (for example, in section 2.1 of the documentation here)
From your description, it seems that the environments are not actually identical. E.g. maybe ENV2 is behind a gateway that adds the Bearer prefix to the header. Or the API on ENV2 (or the gateway) is configured to read the header without the prefix.
When the OAuth Server returns the access token, it gives you the type - a bearer token. That type means, that the token is just this - a bearer token - as opposed to a Proof-of-Possession token. When you send a bearer token to an API, you don't have to provide any additional information that would prove that you are the owner of the token. (you can compare bearer with the DPoP standard)
The Bearer Token Usage standard does require you to use the prefix Bearer in the authorization header (as you pointed out), but it doesn't mean that all the APIs and gateways implement that standard correctly, or that they use that standard at all.
To summarize:
it's up to the gateway/API to decide in what format they want the Authorization header, and that has nothing to do with the type of the token (a bearer token). It's nice when they use standards, but they don't have to.
In your setup, there must be some kind of difference between the environments if the same request is treated differently between them. If you own the environments you should investigate what is configured differently. If you don't own them, you should contact the owner's support to solve the issue.
I am trying to access HERE API example with JetBrains with HTTP files. When I write request this way
GET https://discover.search.hereapi.com/v1/discover?at=52.5228,13.4124&q=petrol+station&limit=5
Authorization: Bearer {{API_KEY}}
I am getting an error
{
"error": "Unauthorized",
"error_description": "Token Validation Failure - unrecognized kid null"
}
And while I am accessing with
GET https://discover.search.hereapi.com/v1/discover?apiKey={{API_KEY}}&at=52.5228,13.4124&q=petrol+station&limit=5
I am getting a normal answer.
Why? Is it just wrong documentation?
Please use your bearer token generated from OAUTH, you can check this post to generate the bearer token from postman or with Python.
https://discover.search.hereapi.com/v1/discover?at=52.5228,13.4124&q=petrol+station&limit=5
Authorization: Bearer {Use your Bearer access token}
When you use "Authorization: Bearer" method don't use API_KEY, but YOUR_TOKEN that you get from OAUTH, more info in documentation https://developer.here.com/documentation/authentication/dev_guide/topics/request-constructing.html
I am trying to send a push notification from my server using Firebase Cloud Messaging but keep getting the following error:
Client error: POST https://fcm.googleapis.com/v1/projects/my-project/messages:send resulted in a 401 Unauthorized response... Request had invalid authentication credentials. Expected OAuth 2 access
I have looked everywhere online and everywhere made mention of "using the Server Key instead of the API Key". I am doing this and still receiving the error. Nothing online has helped.
Here is my request:
POST https://fcm.googleapis.com/v1/projects/my-project/messages:send
Headers:
Authorization: Bearer <MY SERVER KEY>
Content-Type: application/x-www-form-urlencoded (I have also tried application/json)
Body:
{
"message": {
"topic": "",
"notifications": {
"title": "Some title",
"body": "Some notification body"
}
}
}
Push notifications directly from the Firebase console work just fine, I just can't get this to work server side.
It seems you are using the v1 HTTP API, but you're trying to authorize it using the instructions from the legacy API. They aren't compatible. As the documentation states:
Important: The server key found in the console cannot authorize send
requests made via the HTTP v1 API—it is used only for legacy HTTP and
XMPP requests.
If you want to use the v1 API, must follow the instructions in the v1 API documentation. If you don't want to use the v1 API, then you will have to use the legacy API instead.
a customer of ours recently uses ADFS on their Project Server 2016 environment. We have some solutions deployed that communicate with PSI. After using ADFS, the PSI however cannot be reached. We receive following error:
The HTTP request is unauthorized with client authentication scheme 'Ntlm'. The authentication header received from the server was ''.
In ULS, I found following entries:
Claims Authentication 0 Unexpected User-Agent is empty
...
Authentication Authorization agb9s Medium Non-OAuth request. IsAuthenticated=False, UserIdentityName=, ClaimsCount=0
...
Claims Authentication af30r Medium Multiauth SPWebApplication with widnows enabled and MS-OFBA accepted was set to false for the request url 'https://***/PPM/_vti_bin/PSI/ProjectServer.svc'.
General b6p2 Medium Sending HTTP response 401 - text/plain:401 UNAUTHORIZED.
Does anyone have an idea how to solve this? Is there a sample available on how to deal with ADFS and PSI?
I want to develop a SDK that encapsules the OAuth 2.0 functions. I have checked the differences between OAuth 1.0 & 2.0, and I have some confusion on Authorization Header (1.0 and
2.0), OAuth 1.0 protocol parameters can be transmitted using the HTTP "Authorization" header, but I can't find this described in current OAuth 2.0 draft.
Does OAuth 2.0 supports authorization headers?
In OAuth 1.0 your header would look like:
Authorization: OAuth realm="Example",
oauth_consumer_key="0685bd9184jfhq22",
oauth_token="ad180jjd733klru7",
oauth_signature_method="HMAC-SHA1",
oauth_signature="wOJIO9A2W5mFwDgiDvZbTSMK%2FPY%3D",
oauth_timestamp="137131200",
oauth_nonce="4572616e48616d6d65724c61686176",
oauth_version="1.0"
For those looking for an example of how to pass the OAuth2 authorization (access token) in the header (as opposed to using a request or body parameter), here is how it's done:
Authorization: Bearer 0b79bab50daca910b000d4f1a2b675d604257e42
You can still use the Authorization header with OAuth 2.0. There is a Bearer type specified in the Authorization header for use with OAuth bearer tokens (meaning the client app simply has to present ("bear") the token). The value of the header is the access token the client received from the Authorization Server.
It's documented in this spec: https://www.rfc-editor.org/rfc/rfc6750#section-2.1
E.g.:
GET /resource HTTP/1.1
Host: server.example.com
Authorization: Bearer mF_9.B5f-4.1JqM
Where mF_9.B5f-4.1JqM is your OAuth access token.
I just want to specify that you can use "Property Expansion" in the header value as well to Automation your proccess.
( Actually i use a property transfer too, to transfer token into my TestSuite property and then as you can see return it with "${#TestSuite#token}" )
example:
Sources :
pass a property as access token,
Accessing Property
Best regards community !