I want to pass OAuth2.0 authorization credential from my Mule service flow to integrate it with FitBit API.
When I am trying to consume FitBit API from PostMan, there is a provision of "Get New Access Token" which asks user to pass
1) Auth URL 2) Access Token URL 3) Client ID 4) Client Secret (FYI -all these credentials would be generated by FitBit).
My issue here is, I am not sure how these credentials would be passed from Mule?
Can any one please help me to provide some pointer please?
I think your situation is the same as the Github API example in the MuleSoft docs.
Configure the Mule client app for accessing the FitBit API like the example shows for accessing the Github API:
<http:listener-config name="HTTP_Listener_Configuration" host="0.0.0.0" port="8081" doc:name="HTTP Listener Configuration" basePath="/github"/>
<http:request-config name="HTTP_Request_Configuration" protocol="HTTPS" host="api.github.com" port="443" doc:name="HTTP Request Configuration">
<oauth2:authorization-code-grant-type clientId="27...df" clientSecret="ae...6" redirectionUrl="http://localhost:8082/callback">
<oauth2:authorization-request authorizationUrl="https://github.com/login/oauth/authorize" localAuthorizationUrl="http://localhost:8082/login" />
<oauth2:token-request tokenUrl="https://github.com/login/oauth/access_token">
<oauth2:token-response accessToken="#[payload.'access_token']" refreshToken="#[payload.'access_token']"/>
</oauth2:token-request>
</oauth2:authorization-code-grant-type>
</http:request-config>
<flow name="oauth-grant-codeFlow">
<http:listener config-ref="HTTP_Listener_Configuration" path="/" doc:name="HTTP"/>
<http:request config-ref="HTTP_Request_Configuration" path="/user" method="GET" doc:name="HTTP">
<http:request-builder>
<http:header headerName="Accept" value="application/vnd.github.v3+json"/>
</http:request-builder>
</http:request>
<dw:transform-message doc:name="Transform Message">
<dw:set-payload><![CDATA[%dw 1.0 %output application/json
---
payload]]>
</dw:set-payload>
</dw:transform-message>
</flow>
I was also getting the same error while trying to connect with Channeladvisor API.This error comes only when you try to use HTTPS . The solution of this issue is to configure you TLS/SSL setting. Install new certificate for the same.
Thanks,
-Dev
Related
I am creating a OAuth2.0 client for a custom OAuth2 provider in Spring Boot + Security (version 5) application.
Below is the application.properties which has all the configuration and there is no additional configuration class in my project.
spring.security.oauth2.client.registration.xxxxxxxxx.client-id=XXXXXXXXXX
spring.security.oauth2.client.registration.xxxxxxxxx.client-secret=XXXXXXXXXX
spring.security.oauth2.client.registration.xxxxxxxxx.scope=openid
spring.security.oauth2.client.registration.xxxxxxxxx.redirect-uri-template=http://localhost:8080/login/oauth2/code/xxxxxxxxx
spring.security.oauth2.client.registration.xxxxxxxxx.client-name=xxxxxxxxx
spring.security.oauth2.client.registration.xxxxxxxxx.provider=xxxxxxxxx
spring.security.oauth2.client.registration.xxxxxxxxx.client-authentication-method=basic
spring.security.oauth2.client.registration.xxxxxxxxx.authorization-grant-type=authorization_code
spring.security.oauth2.client.provider.xxxxxxxxx.authorization-uri=https://api.xxxxxxxxx.com/authorize
spring.security.oauth2.client.provider.xxxxxxxxx.token-uri=https://api.xxxxxxxxx.com/token
spring.security.oauth2.client.provider.xxxxxxxxx.user-info-uri=https://api.xxxxxxxxx.com/userinfo?schema=openid
spring.security.oauth2.client.provider.xxxxxxxxx.user-name-attribute=name
spring.security.oauth2.client.provider.xxxxxxxxx.user-info-authentication-method=header
When i hit http://localhost:8080/ it redirects properly to provider's login page and after successful login it redirects back to my application.
Now the problem is when it redirects then it shows below error message.
I have googled for this error but didn't get any proper answer. Also, the OAuth2 provider didn't share such URL.
After research I came to know that i need to set below property. Should it be provided by Auth Provider?
spring.security.oauth2.client.provider.pepstores.jwk-set-uri
What exactly I am missing here in configuration?
Finally, the problem is solved. I just need to configure the jwk URI which should be provided by the Auth provider.
Below the final configuration for customer Auth Provider.
spring.security.oauth2.client.registration.xxxxxxxxx.client-id=XXXXXXXXXX
spring.security.oauth2.client.registration.xxxxxxxxx.client-secret=XXXXXXXXXX
spring.security.oauth2.client.registration.xxxxxxxxx.scope=openid
spring.security.oauth2.client.registration.xxxxxxxxx.redirect-uri-template=http://localhost:8080/login/oauth2/code/xxxxxxxxx
spring.security.oauth2.client.registration.xxxxxxxxx.client-name=xxxxxxxxx
spring.security.oauth2.client.registration.xxxxxxxxx.provider=xxxxxxxxx
spring.security.oauth2.client.registration.xxxxxxxxx.client-authentication-method=basic
spring.security.oauth2.client.registration.xxxxxxxxx.authorization-grant-type=authorization_code
spring.security.oauth2.client.provider.xxxxxxxxx.authorization-uri=https://api.xxxxxxxxx.com/authorize
spring.security.oauth2.client.provider.xxxxxxxxx.token-uri=https://api.xxxxxxxxx.com/token
spring.security.oauth2.client.provider.xxxxxxxxx.user-info-uri=https://api.xxxxxxxxx.com/userinfo?schema=openid
spring.security.oauth2.client.provider.xxxxxxxxx.user-name-attribute=name
spring.security.oauth2.client.provider.xxxxxxxxx.user-info-authentication-method=header
spring.security.oauth2.client.provider.xxxxxxxxx.jwk-set-uri=https://api.xxxxxxxxx.com/jwks
Thanks
When you receive JWT in client application, you need to verify the signature of JWT. To verify the signature you need public key of Auth provider. As per OAuth specifications, Auth provider can expose the public key through a URI and client can use this URI to get the public key to validate the JWT. This is what is missing in your configuration.
I am trying integrate Devops with another 3rd part system, but i tried to access Devops from postman using oAuth2.0, but it is always failing, throwing me a error {"Error":"invalid_client","ErrorDescription":"Invalid client auth token."}
Does Devops support oAuth? if so what i am missing so i got this error?
The problem is that DevOps is using non standard headers for some reason. This causes the built in postman to not work. The way that I figured out to work around this is to input the Auth url directly into your browser. You can then extract the auth code from the callback URL.
Then with that code, make a post to the token endpoint in postman
https://app.vssps.visualstudio.com/oauth2/token
Use x-www-form-urlencoded body and fill out the following keys
"client_assertion_type", "urn:ietf:params:oauth:client-assertion-type:jwt-bearer"
"client_assertion", your app secret
"grant_type", "urn:ietf:params:oauth:grant-type:jwt-bearer"
"assertion", your auth code from previous step
"redirect_uri", your callbackurl
Azure DevOps supports oAuth. If you follow the steps in the link below to get an oAuth token, and type the token directly in Postman, you'll get a successful response:
https://github.com/Microsoft/azure-devops-auth-samples/tree/master/OAuthWebSample
I am writing an SSO provider for MS Graph APIs Azure AD v2 endpoint leveraging Spring OAuth2.
I am progressing with the implementation and constant testing but I stumbled upon an error returned by AAD which is puzzling me. After all, this should all be plain standard OAuth 2 flow.
I successfully configured my application on MS dev portal, providing a localhost redirect URL (which, for the record, is the only supporting the http scheme. Kudos to MS). So when I invoke http://localhost/myapp/auth/office365 Spring security successfully intercepts the invocation, provides a correct redirect to my browser with client ID to https://login.microsoftonline.com/common/oauth2/v2.0/authorize with expected parameters.
Microsoft shows a consent screen to me, after which I get redirected back to my Spring Security application via HTTP GET with expected authorization code parameter.
The problem is that when the application tries to negotiate the given authorization code for a bearer token headaches start. Spring Security invokes a POST to https://login.microsoftonline.com/common/oauth2/v2.0/token but ends in 401 error.
Here is the stack trace
error="invalid_request", error_description="AADSTS90014: The request body must contain the following parameter: 'client_id'.
Trace ID: 9acd2a10-1cfb-443f-9c57-78d608c00c00
Correlation ID: bf063914-8926-4e8f-b102-7522d0e3b0af
Timestamp: 2017-10-09 15:51:44Z", correlation_id="bf063914-8926-4e8f-b102-7522d0e3b0af", error_codes="[90014]", timestamp="2017-10-09 15:51:44Z", trace_id="9acd2a10-1cfb-443f-9c57-78d608c00c00"
at org.springframework.security.oauth2.common.exceptions.OAuth2ExceptionJackson2Deserializer.deserialize(OAuth2ExceptionJackson2Deserializer.java:100)
at org.springframework.security.oauth2.common.exceptions.OAuth2ExceptionJackson2Deserializer.deserialize(OAuth2ExceptionJackson2Deserializer.java:33)
at com.fasterxml.jackson.databind.ObjectMapper._readMapAndClose(ObjectMapper.java:4001)
at com.fasterxml.jackson.databind.ObjectMapper.readValue(ObjectMapper.java:3072)
at org.springframework.http.converter.json.AbstractJackson2HttpMessageConverter.readJavaType(AbstractJackson2HttpMessageConverter.java:235)
at org.springframework.http.converter.json.AbstractJackson2HttpMessageConverter.readInternal(AbstractJackson2HttpMessageConverter.java:215)
at org.springframework.http.converter.AbstractHttpMessageConverter.read(AbstractHttpMessageConverter.java:193)
at org.springframework.security.oauth2.client.token.OAuth2AccessTokenSupport$AccessTokenErrorHandler.handleError(OAuth2AccessTokenSupport.java:235)
at org.springframework.web.client.RestTemplate.handleResponse(RestTemplate.java:700)
at org.springframework.web.client.RestTemplate.doExecute(RestTemplate.java:653)
at org.springframework.web.client.RestTemplate.execute(RestTemplate.java:621)
at org.springframework.security.oauth2.client.token.OAuth2AccessTokenSupport.retrieveToken(OAuth2AccessTokenSupport.java:137)
at org.springframework.security.oauth2.client.token.grant.code.AuthorizationCodeAccessTokenProvider.obtainAccessToken(AuthorizationCodeAccessTokenProvider.java:209)
at org.springframework.security.oauth2.client.token.AccessTokenProviderChain.obtainNewAccessTokenInternal(AccessTokenProviderChain.java:148)
at org.springframework.security.oauth2.client.token.AccessTokenProviderChain.obtainAccessToken(AccessTokenProviderChain.java:121)
at org.springframework.security.oauth2.client.OAuth2RestTemplate.acquireAccessToken(OAuth2RestTemplate.java:221)
at org.springframework.security.oauth2.client.OAuth2RestTemplate.getAccessToken(OAuth2RestTemplate.java:173)
at org.springframework.security.oauth2.client.filter.OAuth2ClientAuthenticationProcessingFilter.attemptAuthentication(OAuth2ClientAuthenticationProcessingFilter.java:105)
at org.springframework.security.web.authentication.AbstractAuthenticationProcessingFilter.doFilter(AbstractAuthenticationProcessingFilter.java:212)
at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:331)
at org.springframework.security.web.authentication.AbstractAuthenticationProcessingFilter.doFilter(AbstractAuthenticationProcessingFilter.java:200)
at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:331)
I have looked into Spring security implementation to find the cause,.
It happens that the error message error="invalid_request", error_description="AADSTS90014: The request body must contain the following parameter: 'client_id'. is self explanatory: MS Graph wants the client ID (which is still supplied by the basic authentication header) in the request body. Stop for a moment. I want to use plain old Spring Security and not third-party specific jars in order not to pollute my classpath.
Looking into Java source code of Spring OAuth 2 the problem is damn clear. Spring uses the client ID only in getParametersForAuthorizeRequest, which is used to generate the redirect URL. When it comes to getParametersForTokenRequest the client ID is not specified in the form.
Question: who is right here? How do I tell Spring that MS wants the client id in the token request after an authorization code has been obtained?
Just to clarify, you're not actually authenticating with or against Microsoft Graph. You're actually authenticating against Azure Active Directory. The Microsoft Graph API accepts the bearer token you'll end up with but it doesn't issue the access token itself.
It isn't clear which endpoint you're using for the Authorization Code flow, AAD has two of them: v1 and v2. The primary difference being that v2 uses a central registration and can authenticate both work/school and personal accounts.
Regardless of the endpoint, you do need to supply the clientid in the request body when you're requesting an access token. There are actually several values you need to provide in the body. Also note that these need to be provided as application/x-www-form-urlencoded.
For the v1 endpoint you provide (line breaks for readability only):
grant_type=authorization_code
&client_id={client-id}
&code={authoization-code}
&redirect_uri={redirect-uri}
&client_secret={client-secret}
&resource={resource-uri}
The v2 endpoint is almost identical but uses scope instead of resource:
grant_type=authorization_code
&client_id={client-id}
&code={authoization-code}
&redirect_uri={redirect-uri}
&client_secret={client-secret}
&scope={scopes}
OP's edit
Now, back to Spring Security. Spring by default uses an HTTP basic authentication scheme against Azure AD. In that scheme, the client ID and secret are encoded into the HTTP Authorization header, then the form only contains the authorization code and state parameter, so here is why I (the OP, ndr) was puzzled about why AAD refused the authorization.
In order to pass client ID and secret into the form, we can tell Spring Security to use a different supported authentication scheme. The form authentication scheme will push the client ID and secret into the form.
The below code works and retrieves the access token.
<oauth2:resource
id="msAdAuthenticationSource"
client-id="${oauth.appId}"
client-secret="${oauth.appSecret}"
type="authorization_code"
authentication-scheme="form"
client-authentication-scheme="form"
use-current-uri="true"
user-authorization-uri="${oauth.authorizationUri}"
access-token-uri="${oauth.accessTokenUri}"
scope="${oauth.scopes}"
pre-established-redirect-uri="${oauth.redirectUri}" />
Please note the two
authentication-scheme="form"
client-authentication-scheme="form"
Problem solved, a lot more to come!
The issue I'm having has been discussed several times on this site, however most posts are quite old. Here is something similar to what I'm experiencing. I'm using WSO2 IS 5.2 as my IdP and I have 2 java based web applications hosted on difference servers that participate in SSO. Each webapp (SP) has implemented the Spring-SAML extension. Single Sign-On works perfectly but Single Logout only partially works. Here is the test case:
Access secure resource on webapp1
Login page from Idp (WSO2) is presented and user logs in
Secure resource from webapp1 is presented
Access secure resource on webapp2
SAML request is sent to Idp, Idp responds and user is authenticated
Secure resource from webapp2 is presented, end SSO
Initiate single log out from webapp2
Webapp2 send saml request (through browser) to Idp and saml response is returned
User is logged off locally on webapp2 and Idp session is terminated
The IdP directly sends logout request to webapp1 (back-channel type)
Logout request fails to webapp1 (log indicate SamlStatusException: No user is logged in)
So the end result is that I still have a local session on webapp1. If I change the order and initiate SLO from webapp1, then webapp1 will be logged out and webapp2's local session will continue to exist. The WSO2 server is able to determine the 2nd session participant during SLO, however the HTTP request sent from the Idp to the 2nd session participant does not have a Spring security context. This would be a stateless HTTP request so there wouldn't be a logged in user. This is why I believe it is failing.
I found this discussion. Its about 2 years old. Is there anything new on this issue? Maybe a configuration step missed by me on WSO2 or in the Spring-saml config.
Here is a relevant piece of my SP metadata:
<md:SingleLogoutService Location="https://tpap10-wwwdev04.arbfile.org:443/webapp/saml/SingleLogout" Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"/>
<md:SingleLogoutService Location="https://tpap10-wwwdev04.arbfile.org:443/webapp/saml/SingleLogout" Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect"/>
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</md:NameIDFormat>
<md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</md:NameIDFormat>
<md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:persistent</md:NameIDFormat>
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified</md:NameIDFormat>
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName</md:NameIDFormat>
<md:AssertionConsumerService Location="https://tpap10-wwwdev04.arbfile.org:443/webapp/saml/SSO" Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" isDefault="true" index="0"/>
<md:AssertionConsumerService Location="https://tpap10-wwwdev04.arbfile.org:443/webapp/saml/SSO" Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact" index="1"/>
Some relevant Spring-Saml config on the SP:
<bean id="metadataGeneratorFilter" class="org.springframework.security.saml.metadata.MetadataGeneratorFilter">
<constructor-arg>
<bean class="org.springframework.security.saml.metadata.MetadataGenerator">
<property name="entityId" value="urn:webapp1:mycity"/>
<property name="entityBaseURL" value="https://wwwdev04.domain.org:443/webapp" />
<property name="extendedMetadata">
<bean class="org.springframework.security.saml.metadata.ExtendedMetadata">
<!-- <property name="signMetadata" value="false"/> -->
<property name="idpDiscoveryEnabled" value="false"/>
</bean>
</property>
</bean>
</constructor-arg>
</bean>
WSO2 was not implementing the SAML 2.0 specification correctly. The specification requires that Single Logout with HTTP-* bindings is done using front-end channel (= through user's browser) - which makes the HTTP session available and allows Spring SAML to terminate it correctly. I believe that this issue was never fixed in WSO2.
Spring SAML uses HttpSession for storage of user's state by default. This is also the reason why Spring SAML doesn't support Single Logout with SOAP binding out of the box. It would be possible to implement an application-wide storage of Spring Security sessions which could be invalidated independently from the HttpSession (and therefore work-around the WSO2's limitation), but this is not configured by default (and I have never tried it).
We are trying to implement Google's OAuth 2.0 cross-client sign-on functionality so that our server keeps the tokens and associates them with users, as shown in the diagram for the flow here: Google OAuth 2.0 Server-Side Flow
I am able to successfully retrieve a one-time access code on the client app. I then send that code to the server via a post to "http://example.com/oauth2callback/code="
It gets to the server just fine. The server then attempts a POST to Google that looks like this:
POST /o/oauth2/token HTTP/1.1
Host: accounts.google.com
Content-Type: application/x-www-form-urlencoded
code={My Code}&
client_id={My Client ID}&
client_secret={My Client Secret}&
redirect_uri="http://example.com/oauth2callback"&
grant_type=authorization_code
However, each time the server is returning "Error: redirect_uri_mismatch."
We have tried everything. We double-checked the redirect_uri matches EXACTLY in the Google console and the client ID and client secret are correct. It still doesn't work. Any ideas?
In the "server-side" flow your redirect_uri should be set to postmessage. Unfortunately that is not clearly documented by Google. See also Google OAuth 2.0 "error" : "redirect_uri_mismatch" and related questions/answers.
We figured this out eventually, but I wanted to post this here so that others can find it. It turns out that you should NOT specify a redirect URI if you are exchanging a one-time access code for an access token via communicating with Google's servers from your own server. Instead, it should look like this:
POST /o/oauth2/token HTTP/1.1
Host: accounts.google.com
Content-Type: application/x-www-form-urlencoded
code={My Code}&
client_id={My Client ID}&
client_secret={My Client Secret}&
redirect_uri=''&
grant_type=authorization_code