How to allow user to input client id and client secret in swagger? This is what i have for security definition but It prompts accesstoken which is obtained through client_id and client secret, but I have not been able to make it ask client id and client secret?
securityDefinitions:
api_auth :
type: oauth2
authorizationUrl: 'https://randomapi/aa/token.oauth2'
flow: implicit
scopes:
I also had the same issue. What worked for me was to define flow as application :
flow: application
Related
SETTUP:
We have an application which needs to authenticate itself to an API with help of ADFS. For this it seems suitable to use Client Credentials Grant Flow;
https://learn.microsoft.com/en-us/windows-server/identity/ad-fs/overview/ad-fs-openid-connect-oauth-flows-scenarios#client-credentials-grant-flow
So in ADFS I created a new application group with a server application and a Web API with the following setup,
Server Application:
Client Id: client1
Client Secret: (some-guid)
Web API:
Relying parties: client1
Access control policy: Permit everyone
Client permmissions --> Client Application: client1
Permitted scopes: openid profile allatclaim
Then I request a token via https://.../adfs/oauth2/token with
client_id=client1
client_secret=(some-guid)
grant_type=client_credentials
I received a JWT token with aud and appid as expected:
"aud": "microsoft:identityserver:client1"
"appid": "client1"
PROBLEM:
The problem becomes when I want to add another client to use with the API. So I change my setup to,
Server Application 1:
Client Id: client1
Client Secret: (some-guid)
Server Application 2:
Client Id: client2
Client Secret: (some-guid)
Web API:
Relying parties: client1, client2
Access control policy: Permit everyone
Client permmissions --> Client Application: client1, client2
Permitted scopes: openid profile allatclaim
Then when I request a JWT token with the credentials of client2 (client_id and client_secret) I get:
"aud": "microsoft:identityserver:client1"
and the same if I use client1. I tried to add different relying parties in the Web API and it seems like it always sets the aud in the JWT to the first RP in the list (alphabetic order). For instance, if I also add 123 as a RP in the Web API then the "aud" becomes "microsoft:identityserver:123" for both client1 and client2.
If I instead remove all relying parties and add a the url to my api then the aud in JWT token becomes "urn:microsoft:userinfo".
From what I have read, the aud field in the JWT token should contain all principals who will process the JWT token. See https://www.rfc-editor.org/rfc/rfc7519#section-4.1.3.
QUESTIONS:
How should a setup my Application group to be able to have multiple clients?
Can ADFS sent multiple audiences instead of only the first one?
Or have I used the wrong approach?
Kind regards, Jesper
Through trial and error I finally find how to solve this!
The relying parties in the Web API should only contain identifiers for the Web API (not the Server Applications) for instance this could be an address like "https://mywebapi.com".
Client permission --> Client Applications should contain the Server Applications that should be allowed to talk to this server.
Then when requesting a JWT token from ADFS you also need to include the parameter "resource" which value should be one of the identifiers of the Web API. Hence the call body of the call becomes
client_id=client1
client_secret=(some-guid)
grant_type=client_credentials
resource=https://mywebapi.com
I tried to search for the resource field to find out more about it but couldn't find any explanation or any site using it.
I've spent the last couple days trying to set up Cognito to use Battle.net OIDC. I believe I am most of the way there. I can see using the cognito hosted UI that it authenticates correctly but then fails, presumably trying to retrieve the token.
The first request to cognito hosted UI:
https://<removed>.auth.us-west-2.amazoncognito.com/oauth2/authorize?identity_provider=Blizzard&redirect_uri=https://<my-site-oauth-handler-removed>/oauth&response_type=CODE&client_id=<removed>&scope=openid
Then the next request is to Battle.net OIDC as expected:
https://us.battle.net/oauth/authorize?client_id=<removed>&redirect_uri=https%3A%2F%2F<removed>.auth.us-west-2.amazoncognito.com%2Foauth2%2Fidpresponse&scope=openid&response_type=code&state=<removed>
Then the code is passed onto the cognito idpresponse:
https://<removed>.auth.us-west-2.amazoncognito.com/oauth2/idpresponse?code=<removed>&state=<removed>
At this point, if my understanding is correct cognito should try to hit the battle.net /oath/token endpoint and then return the id_token and access_token to my redirect_url. It is at the point cognito instead returns an error to my url:
https://<my-site-oauth-handler-removed>/oauth?error_description=Bad+id_token+issuer+oauth.battle.net&error=invalid_request
Judging by the lack of documentation for Battle.net OIDC I may be one of a handful trying to use the battle.net OIDC with Cognito. It very well could be a bug with their implementation but I'm trying not to jump to that conclusion.
My best guess right now is that I haven't configured Cognito correctly to make the token POST request. It needs to use Basic Authentication with the clientid:password but I can't verify if it's doing that correctly or not since its abstracted away.
Anyway, when I make the request through my app (using amplify to open the hosted UI) it does return but with the following:
[ERROR] 51:05.25 OAuth - Error handling auth response. Error: Bad+id_token+issuer+oauth.battle.net
at OAuth.<anonymous> (OAuth.js:202)
at step (OAuth.js:52)
at Object.next (OAuth.js:33)
at OAuth.js:27
at tryCallTwo (core.js:45)
at doResolve (core.js:200)
at new Promise (core.js:66)
at __awaiter (OAuth.js:23)
at OAuth.handleAuthResponse (OAuth.js:181)
at AuthClass.<anonymous> (Auth.js:1632)
Here is all my relevant Cognito configuration:
OIDC Provider:
Provider Name: Blizzard
Client ID: [removed]
Client Secret: [removed]
Attributes request method: POST
Authorize scope: openid
Issuer: https://us.battle.net/oauth
App Client:
Name: [removed]
App client id: [removed]
App client secret: (no secret key)
App Client Settings:
Enabled Identity Providers: Blizzard
Callback URLs: https://[removed]/oauth
Sign out URLs: https://[removed]/oauth
Allowed OAuth Flows:
Authorization code grant
Implicit grant
Allowed OAuth Scopes
email
openid
aws.cognito.signin.user.admin
profile
(I've tried every variation of these and it doesn't appear to change the outcome)
Federated Identity:
Authentication providers
OpenID
us.battle.net/oauth
IAM Identity Providers:
Provider Name: us.battle.net/oauth
Provider Type: OIDC
Provider URL: us.battle.net/oauth
CA Thumbprint: [removed]
Audience: [my battle.net client id]
I have exhausted my own resources and am asking for any guidance with this.
Thanks!
This was caused by Blizzard issuing their tokens from their well-known endpoints but setting the iss field to oauth.battle.net which caused Cognito (or any other token validation) to fail hence the error message
Bad+id_token+issuer+oauth.battle.net
I brought this up to their API team in Discord and they are releasing a fix on November 25th according to an email send to developers.
Dear community developer,
Earlier this year, we introduced a new OAuth discovery endpoint which
implements the OpenID Connect discovery specification. We would like
to deploy a change to the issuer field iss of the id_token during the
OpenID authorization flow from oauth.battle.net to the issuer that is
returned by the well-known configuration endpoint JSON response. This
would be a potential breaking change to some of the OAuth OIDC clients
but it conforms to the OpenID connect specification:
https://openid.net/specs/openid-connect-core-1_0.html#IssuerIdentifier
Your OAuth client application was identified as one that could be
affected by this change.
We are planning to release this change on November 25, 2019.
Here are the steps that you can take to ensure your OpenID Connect
client will continue working after the change:
Navigate to one of the well-known configuration endpoints below which
corresponds to the region where your client application operates and
check the "issuer" field.
If the issuer field matches the configured issuer for your OAuth OIDC
client then your client is compatible and you are already compliant
and do not need to make any changes.
If the issuer field from the well-known configuration endpoint is
different than the issuer set in your client configuration, please
change the issuer to match the well-known configuration endpoint.
If your client supports the OpenID discovery endpoint standard, you
can configure it to read all necessary settings from the well-known
configuration endpoint. Your OAuth client should self-configure.
I am using oAuth Model to access Podio API. I am able to generate the Access Token and Refresh Token using a pair of Client ID and Client Secret.
Later when i tried to authenticate using previously generated Access Token and Refresh Token with new pair of Client ID and Client Secret then getting Following Error Message:
{"{\"error_propagate\":false,\"error\":\"invalid_grant\",\"error_description\":\"Invalid refresh_token\",\"error_detail\":\"different_client_id\",\"request\":{\"url\":\"http://api.podio.com/oauth/token\",\"query_string\":\"\",\"method\":\"POST\"}}"}
When i tried to authenticate using same Pair of Client ID and Client secret that was originally used to generate the Access Token , it Works.
My Question is: Can we use different Client ID and Client Secret to authenticate through Access Tokens that were generated using different Client Id and Secret.
I hope i have clearly described my question.
No, access tokens are tied to a specific client and secret. Allowing access tokens to be used with other clients would be a security hole.
I've seen these questions about using Postman in order to invoke Google's API with OAuth 2:
Using Postman to access OAuth 2.0 Google APIs
Could not obtain Google oAuth 2 token on POSTMan
and many more, but they all have client ID and client secret.
For the 'Save to Android Pay' API, all I got is a .p12 key and an issuer ID. I also have Service Account Email Address but defiantly no client id or secret. I think I also have the Auth URL but I'm not sure: https://www.googleapis.com/auth/wallet_object.issuer
Looking in the Save to Android Pay API, doesn't say anything about a client id so I'm really not sure how I'm supposed to obtain a token in POSTMAN with what I have.
So my question is: giving a .p12 key, an issuerId and a Service Account Email Address, What do I need to fill in POSTMAN OAuth 2 fields:
Token Name, Auth URL, Access Token URL, Client ID, Client Secret, Scope (Optional), Grant Type
To obtain OAuth 2.0 client credentials, you need to register an application to the Google API Console as specify in the basic steps and then you'll get a client ID and client secret.
I'm trying to understand what each string in the Oauth 1 scheme does.
As per my understanding, the consumer key and consumer secret are used to sign a request to the api, from the calling application, and the access_token and access_secret pair are used as a proxy for the user's login credentials.
Am I right in my understanding?
Not quite. The consumer key is a value that identifies the client application that is being used to access the user resources, and the access token is the value that provides the authorization to access those resources.
A combination of the consumer secret and token secret are used to sign the request which provides verification that the request is being sent by an authorized party.
You can read more about the definitions of the oauth 1.0a spec here.