Am trying to utilise Salesforce named credentials (legacy) to connect to a custom built external API, and seeking guidance for what (or where to find) the format of the 'standard' auth response Salesforce expects in order for it to then be able to extract returned tokens etc for use in subsequent callouts.
Currently, the response from the auth endpoint Im hitting is in JSON format payload returned in response body. I have to parse the json for my access token, and then (I guess) store that token for subsequent use. Is this typical, or am I not using named credentials properly? Is token management my responsibility or ideally part of what named credentials manages?
I'd have thought that once I hit the auth endpoint and got sent a token in some 'expected' response format, salesforce named credentials would store and pass that token in any subsequent callouts - or do I have it all wrong?
Any pointers most appreciated!
Related
I am trying to integrate Quickbooks online with Mule. So far, I can complete the OAuth dance and retrieve the access token via the HTTP connector using the authorization code configuration.
The steps followed include:
COnfiguring the HTTP Request connector for OAuth dance which includes
Added authorization, callback URL, token URL, and client credentials
Configured payload for saving the access and refresh tokens
To trigger the oauth flow , I hit the authorize URL which in return gives me the realmId and authorization code
To make subsequent requests to the APIs using the extracted token I need the realm ID as well but I am not able to extract that.
The realmId is returned in the initial call along with the authorization code in the payload but when the process happens through mulesoft, there is no way to capture it and without the realmId I cannot make requests to the API.
Following is the XML configuration for HTTP:
<http:request-config name="HTTP_Request_configuration" doc:name="HTTP Request configuration" doc:id="36a1c561-9498-4dbf-b323-5c726b20cb6a" >
<http:request-connection protocol="HTTPS" host="sandbox-quickbooks.api.intuit.com" port="443">
<http:authentication >
<oauth:authorization-code-grant-type externalCallbackUrl="http://localhost:8082/callback" localAuthorizationUrl="https://localhost:8082/login" authorizationUrl="https://appcenter.intuit.com/connect/oauth2" clientId="ABNxxKq4xy1KWs1BteaIIAhY3NC7G5jg9YZg3h15Zf3waDdEja" clientSecret="5k5GxV3HIBtM7DRSQOqlBqtjWfg07tFNAFeW9EeJ" tokenUrl="https://oauth.platform.intuit.com/oauth2/v1/tokens/bearer" localCallbackUrl="http://localhost:8082/callback" state="abc" scopes="com.intuit.quickbooks.accounting">
<oauth:custom-parameter-extractors >
</oauth:custom-parameter-extractors>
</oauth:authorization-code-grant-type>
</http:authentication>
</http:request-connection>
</http:request-config>
I need a way to extract the realmId and set it dynamically instead of hardcoding.
[This is the first request which gets the auth code and realmId before token exchange][2]
This is how realmId will be used in subsequent requests after token exchange
It is to be noted that I am not manually saving and reusing any variables, it is all happening as part of the Mulesoft HTTP connector oauth config
Reference guide for oauth in Mulesoft
I've been provided with a REST API which has authentication type bearer (Security Scheme Type: API Key, Header parameter name: Authorization) and which i use to authenticate the user and then fetch other data (i will only create the front end using react).
As a first step the user logs in and i sent his/her username-password to the prementioned REST API and get back an access and a refresh token.
Is anything wrong with storing these 2 tokens in a cookie in order to use them in subsequent requests? How does JWT comes into play regarding these 2 tokens? Is JWT of any use to me in this situation?
There's nothing wrong in storing the tokens in cookies, but if you're planning to have a Single Page Application with React it should be enough to store these tokens in memory. Once the user refreshes the page you can either make them sign in again or perform a silent login in the background to get a new set of tokens. In both cases the session kept on the Authorization Server should kick in and you should get new tokens without the need of user interaction.
Your tokens will be much safer if you don't keep them in cookies.
JWTs are not a requirement for access and refresh tokens. If you don't have to use them I would recommend going with opaque tokens. That said, since you do not have control over the API you might be limited to the format required by the API. If you don't want to be limited by this format you can set up your own gateway which you can use to perform token exchange or introspection and forward requests to the API with proper tokens (something which is called a Phantom Token pattern.
From my understanding of the question, you are using an identity provider which provides you with access token and refresh token for the users. That means it is a authentication as a service REST API at works here.
The REST API requires an authorisation header to be passed along with the username-password to exchange for access token and refresh token for the users. (correct me if I'm wrong) In this case, you might want to keep the authorisation header away from the users (consult the authentication as a service documentation).
You call the REST API with payloads (the user-password) along with headers like this:
Authorization: ACCESS_TOKEN
However the ACCESS_TOKEN is the one provided by the vendor for you to use the REST API. On success call of the REST API, it should return you with a set of access token and refresh token. You can then use this access token and refresh token to safe guard your own API, API that you control to provide service to your users.
The access token and refresh token might just be JWT tokens (again consult the vendor documentation).
Also if you are using an authentication as a service REST API, check the documentation if they provide a client sdk. In that case, it should show you the best practise of handling the access token and refresh token it returned.
Is it possible to use the an access token requested by another API endpoint to MS Graph to another API endpoint?
Scenario:
API Endpoint A requested an access token and receive the access token and store it to the database.
API Endpoint B used the access token being stored in the database by
API EndPoint A.
NO!
A token can only correspond to one api. The access token is issued according to the api audience you want to access, and it is unique! A token can only have one aud, and you cannot use multiple scopes to request access tokens. If you need to access other api endpoint, you should obtain a token for each api endpoint separately.
Your idea is indeed feasible for some of the same types of api endpoints. For example, if two identical MS Graph APIs endpoint have the same permissions and user role requirements, you can indeed use API A's access token to call API B, but for security reasons, I don't recommend you to do this.
I'm working on a SPA application, and I'm using the recommended implicit flow and I'm able to get access_token and id_token. As I need more than the profile info, I've created a separate endpoint to return the user profile information (along with all the other information that's specific to our business) and this endpoint is protected, and can be accessed only with an access_token as the bearer token. Right after getting access_token in SPA, I call this endpoint to get all the user information (which includes first name, last name etc., that gets displayed on the UI). If there is any problem with the returned id_token and access_token pair, the user profile info endpoint call would fail. So, do I really need to validate the id_token? as I'm not relying on any information within that token.
For authenticating against external login provider or authorization code flow, validating the id_token makes sense, but in my case I'm not sure about it.
According to OpenID spec:
When using the Implicit Flow, the contents of the ID Token MUST be validated in the same manner as for the Authorization Code Flow, as defined in Section 3.1.3.7, with the exception of the differences specified in this section.
1. The Client MUST validate the signature of the ID Token according to JWS [JWS] using the algorithm specified in the alg Header Parameter of the JOSE Header.
2. The value of the nonce Claim MUST be checked to verify that it is the same value as the one that was sent in the Authentication Request. The Client SHOULD check the nonce value for replay attacks. The precise method for detecting replay attacks is Client specific.
Why don't you utilise response_type parameter in authorisation request. By changing its value, you can alter what you receive for authorisation response.
Identity documentation mention about possible response type values. Following is an extraction from their documentation,
As you can see, if you do not want SPA to receive the id token, you can set the response_type value to token. If you do so you will only get an access token, which is enforced by OAuth 2.0 specification. (See the OAuth 2.0's implicit flow response_type explanation from here). Note that when you use response_type=token , you are using OAuth 2.0 (not OIDC)
I don't see any wrong in your approach as long as you utilise features enabled by respective protocols.
I'm currently developing an App using Microsoft LIVE 2.0 API
Currently, I’m using these URLs as my authentication endpoints:
https://login.microsoftonline.com/common/oauth2/v2.0/authorize
https://login.microsoftonline.com/common/oauth2/v2.0/token
However, when I sent the request to the token endpoint with the redirect URL as
https://blabla.com/accept_token.php?api_ver=wave5&csrf=AY7F6O4hF0n8yW3i2O_y6N-ky7zzfULiYV_fttLK1S3JgaeQz2GTk9FOeIGBBH5CvkfkEYCyPOCQCujcrij4KDy2wAMZyXqx24jvwZRtzOv0s9ADGYl1iFtvYtkmgeFmZEY&appdata=%7B%22use_case%22%3A1%2C%22type%22%3A1%2C%22flow%22%3A2%2C%22domain_id%22%3A12%2C%22tracked_params%22%3A%22%5B%5D%22%7D
I got errors saying the reply address does not match the reply addresses configured for the application
For the application, I set the reply address to be https://blabla.com/accept_token.php.
Is it possible that I add some parameters to the url and still make it match?
I'm pretty sure the reply url you send must match exactly the reply url registered on the application, including any query strings.
If there is variable state informaiton you need passed throughout the authentication process, you should use the state variable.
https://learn.microsoft.com/en-us/azure/active-directory/develop/active-directory-v2-protocols-oauth-code
state
A value included in the request that will also be returned in the token response. It can be a string of any content that you wish. A randomly generated unique value is typically used for preventing cross-site request forgery attacks. The state is also used to encode information about the user's state in the app before the authentication request occurred, such as the page or view they were on.