New answers tagged

1

TL;DR - It's not okay, don't use it. Instead, go with the authorization code grant type (aka Web Server flow in Salesforce world). Full story: The user-agent flow in Salesforce is based on oAuth implicit grant type with one difference - refresh token. You only get the refresh token if you ask for it explicitly with scope = refresh_token and your flow ...


0

You're mixing up two flavors of the authorization available in MC - the so-called "legacy" flow which relied on JWT and the newer oAuth-based flows which do not rely on JWT. (The core SF platform underneath Sales Cloud et al does support auth flows with tokens encoded as JWTs). The legacy flow has been retired as of August 1, 2019. /v2/authorize is part of a ...


1

The answer was the audience oauth parameter for community users must be community url, instead of test.salesforce.com on sandbox. According to docs: The audience (aud) identifies the authorization server as an intended audience. Use the authorization server’s URL for the audience value: https://login.salesforce.com, https://test.salesforce.com, or https://...


2

It is fully supported; this should work: <script type="javascript" runat="server"> Platform.Load("core","1.1.5"); var authEndpoint = "your subdomain"; var client_id = "your clientId"; var client_secret = "your client_secret"; var account_id = "your account_id"; var grant_type = "client_credentials"; // auth ...


5

The ClientID and ClientSecret properties for the new API-Version using OAuth2 are named differently, so you need to change "clientId" to "client_id" and "clientSecret" to "client_secret". Additionally there are some changes which are already correct in your code snippet, but for the sake of completeness: the token in the response is now contained in "...


0

I'm not 100% sure that you can do this from within the same org that you're trying to auth with (I'm only about 98% confident that it does work), but you can use an anonymous apex window to test this. You can use Apex to construct everything you need, but the simpler approach is to use some of the classes in the Auth namespace (Auth.JWT, Auth.JWS, and Auth....


0

To create the JWT assertion, you can use a tool such as jwt.io. You'll need your private key. Since jwt.io is a 3rd party, only use it for testing in a non-production environment. The public/private key should be deactivated (deleted/rotated/etc) when you're done with your test. Grab the JWT header and payload from examples in SF doc Replace the values of ...


3

"Authentication without credentials" is fairly close to being a misnomer. By definition, if you want to authenticate a caller, you need some kind of credentials, and the best and most secure solution is to use a Salesforce user authenticated via OAuth. There is another option that is suitable for specific situations, but is not a general-purpose replacement ...


1

Sort of. You only get the refresh token if you ask for it explicitly with scope = refresh_token and your flow meets other documented constraints such as custom protocol on the callback URL. We agree that this "extension" is not compliant with implicit grant type spec. If memory serves, it was created by SF for mobile apps a while ago. While some might ...


2

You'll need to roll your own client that implements the oAuth authorization code flow with PKCE extension. As you found out, Named Credential won't help you. The common wisdom is that tokens should be stored in custom settings and/or custom metadata. The latter can be updated via the Metadata API. You will also need to store the code verifier until it's ...


1

Make sure your AuthProvider name has no spaces. I was able to pull the metadata using the retrieve command: sfdx force:source:retrieve -m AuthProvider However, your subsequent pull commands will continue to fail because it cannot find the AuthProvider. If you rename it replacing spaces with underscores (Name and URL Suffix will both have no special chars)...


Top 50 recent answers are included