How and when does a Salesforce SAML / OAuth2 user give permission to use a connected app?

We created a Salesforce Connected App which should get its access token using SAML / OAuth2.

The request looks as follows:

https://test.salesforce.com/services/oauth2/token?grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Asaml2-bearer&assertion=[SAML_ASSERTION]&saml=[SAML_CODE]

It produces the error message:

400 (Bad Request)
{"error_description":"user hasn't approved this consumer","error":"invalid_grant"}

With grant_type = authorization_code, the salesforce user is prompted with a screen asking him to give the connected app approval, but how is it with grant_type = urn:ietf:params:oauth:grant-type:saml2-bearer ? Will the user also be prompted? And when? and how will the prompt open? Or is with saml2-bearer or a pre-approval possible?

Thanks for giving me some insights!

Answers:

Thank you for visiting the Q&A section on Magenaut. Please note that all the answers may not help you solve the issue immediately. So please treat them as advisements. If you found the post helpful (or not), leave a comment & I’ll get back to you as soon as possible.

Method 1

After some extensive trial and error I finally found the solution for the error:

> {"error_description":"user hasn't approved this
> consumer","error":"invalid_grant"}

For whatever reason, the salesforce SAML/OAuth2 implementation needs to have the “Refresh Token” scope assigned in the Connected App settings. Without it – this error – appeared.

In the regular User/Password prompt OAuth2 Salesforce implementation this isn’t required.

I managed to get it work on our Salesforce testportal using the built in Salesforce Identity Provider enabled.

Method 2

According to the OAuth 2.0 SAML Bearer Assertion Flow docs,

The OAuth 2.0 SAML bearer assertion flow defines how a SAML assertion
can be used to request an OAuth access token when a client wishes to
utilize a previous authorization.

That might be an interactive user authorization via the web server flow (aka ‘authorization code grant type’), or, more likely, admin authorization via the admin console.

Connected apps are added to the list at Manage Apps | Connected Apps either implicitly, the first time they are accessed by a user in that org, or explicitly, by an admin via the app’s install URL. Either way, in the Connected App Edit page, the admin has control over which users can access that app.

Editing Connected App Policy

By default, users self-authorize access by clicking through the OAuth flow, but you can change ‘Permitted Users’ to ‘Admin-approved users are pre-authorized’ and specify profiles and/or permission sets pre-authorized to access the app.

So, create an appropriate profile or permission set, assign it to the user(s) in question, set ‘Permitted Users’ to ‘Admin-approved users are pre-authorized’, add the profile/permission set to the app, and your OAuth request should succeed.

Method 3

You may get this error if you haven’t authorized the connected app for the user yet.

enter image description here

You can do this by logging in with the standard oAuth webflow.


All methods was sourced from stackoverflow.com or stackexchange.com, is licensed under cc by-sa 2.5, cc by-sa 3.0 and cc by-sa 4.0

0 0 votes
Article Rating
Subscribe
Notify of
guest

0 Comments
Inline Feedbacks
View all comments
0
Would love your thoughts, please comment.x
()
x