If you notice the token_type value, its 'bearer' and I want the module to return 'Bearer' as it is causing issues when the consumers are sending back the Authorization header (OAuth2 provider validate component is expecting the value to be Bearer <>) .

I understand the OAuth2 spec itself is bit ambiguities as it says token_type to be case insensitive while it expects Authorization to be 'Bearer <>'

9 Replies

@anandajjarapu_muley If you have your own Oauth provider in Mule you can always control the oauth in flow level. There is a property called preFlow-ref in Mule oauth provider which refer to a mule flow of your choice. There in that flow you can validate, or even correct the case sensitivity of authorization header before it hits the actual mule oauth provider

Another alternative way is to control this from policy level. If you have your own custom ouath policy you can control, validate or even fix this case sensitivity before your token is validated from oauth provider server

Best way is to use custom oauth policy

--------------- Update :

Based on your previous answer, in Mule 4 there is the expression #[(attributes.headers['authorization'] splitBy ' ')[1]] in oauth2-provider:validate-token component for validating the access token.
It takes only the access token and not Bearer or bearer from the expression. I don't see any issue in Mule 4 oauth provider in case sensivity . It even doesn't bother the token type if you have Mule 4 oauth provider implemented during validation of access token. But in your question you have mentioned that you are getting a response like:

{
"token_type": "bearer"
}

which is a Mule 3 oauth provider response which suggest you have Mule 3 oauth provider implemented and not mule 4. So, you can control the token type case sensivity with above mentioned custom policy

Sure! Sorry, It's not an issue really but just the behavior is a bit silly.

Upon receiving the token, client is trying to send the token as part of the header as follows - Authorization: - bearer <>. unless the client sends it as 'Bearer <> (notice here 'B') OAuth2 module doesn't allow the consumer to consume the service.

It looks like this is as per the specification but some of the providers such as AWS, CRM etc.. treat 'Bearer ' to be case insensitive and allow regardless of whether the client sends 'bearer <>' or 'Bearer <>' and it make sense as well.

I am wondering if there is any way in MuleSoft OAuth module to treat the 'Bearer' case insensitive.

@anandajjarapu_muley how does that matter? After getting the token either you are going to pass the token in a rest client like postman or you are going to call the secured API in your Mule flow. Now if you are going to call your secured API using Postman client, you can easily copy the oauth token and put as a header in Authorization and manually put the token as value in postman as Bearer <>

If you are calling the API from your mule application or flow, you can use the following example:

I know! There are multiple ways to achieve this from client perspective. We could even set 'access_token' as a http header property and assign the token.

If you think about it (from the provider side), it just sounds silly and doesn't look obvious when other providers (most of them) make it case insensitive. I don't know if there is any particular reason behind it though.

Nevertheless, we are asking our consumers to make sure they send 'B' not 'b'. I thought someone might have felt the same way as I am and found a solution to make it more obvious. But, thank you for your inputs! Appreciate it!

@anandajjarapu_muley Also in Mule 4 there is the expression #[(attributes.headers['authorization'] splitBy ' ')[1]] in oauth2-provider:validate-token component for validating the access token. It takes only the access token and not Bearer or bearer from the expression. I don't see any issue in Mule 4 oauth provider in case sensivity

Sign up for our newsletter

MuleSoft provides a widely used integration platform for connecting SaaS and enterprise applications in the cloud and on-premises. Delivered as a unified integration experience, CloudHub™ and Mule ESB™ (enterprise service bus) are built on proven open source technology for fast and reliable on-premises and cloud integration without vendor lock-in. Our solutions also include Tcat, an Apache Tomcat server for enterprises.