0

I'm new with using OAuth2 and want to use it to allow endpoint users to be authenticated with their accounts using LDAP. While the authentication process works, I see that you must send the client ID and client Secret of the app with every request token.

From what I can guess, it is a terrible idea to store the client ID and Secret in the client-level app. The way I thought of going about it is to make a small "authentication service" that will receive the user's data (LDAP Username & Password or other methods in the future), and return the OAuth2 token. That service will have access to the client ID and Secret that will be stored securely.

Is this the right approach for this and does this apply the best practices with Oauth2? Or is there a better way to authenticate end users without them having access to the client secret at client side?

0

The Client Secret, as you've guessed, should be treated like a password, and not exposed to anyone, as it allows them to impersonate your app. You're using the wrong OAuth2 flow. Use the User-Agent OAuth2 Flow instead, or the SAML Assertion Flow (I believe this is actually the one you want). These flows do not expose the Client Secret to the client, as it does not need it. They are secure through other means.

0

The oAuth flow you want is the authorization code grant, aka Web Server in Salesforce universe. No other flow is safe for a public client, a type of client in oAuth that cannot adequately protect a secret. By default, a browser-based app or a native app (desktop, mobile, ...) cannot do so. See this Q&A for more info.

As an alternative to oAuth, you could authenticate to Salesforce via credentials in your on-premises LDAP service by going through Delegated Authentication. This is an older option but it's still very much available and doable:

You can use any authentication method as long as you wrap it in a web service that Salesforce can consume. For example, you can use a Lightweight Directory Access Protocol (LDAP) server as your authentication method and wrap it in a SOAP-based web service. After you integrate the authentication backend with Salesforce, you can use Salesforce permissions to control which users log in with delegated authentication rather than with Salesforce credentials.

You build the aforementioned web service and deploy it on your premises. When user attempts to authenticate with Salesforce via username/password, Salesforce will call your web service and your web service will talk to your LDAP service.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.