SAML authentication flow from non-browser clients

Help
1

Hi, my goal is to be able to authenticate a user given their username/email and password directly from a service provider to an SAML identity provider without using a web-flow (no browser). The use case is to authenticate using non-browser clients, such as a command-line tool. In other words, I want to be able to programmatically interact with the SAML identity provider on behalf of the user.

I am able to achieve this through the Auth0 API directly for database-based connections using the Authorization Code endpoint. I see there is a set of SAML endpoints as well, but I can figure out the programmatic flow for this.

Any help would be appreciated. Thanks!

2

If I understood the scenario correctly then to my knowledge SAML does not provide that ability; the token endpoint with resource owner password (Authentication API Explorer) does allow the direct exchange of credentials for tokens when those credentials are associated with database connections or if I recall correctly an AD Connector instance. However, for a SAML connection that would not be possible.

The command-line tool should make use of an OAuth 2.0 flow through a system web-browser where the redirects associated with SAML authentication could be performed and then the authentication response would be communicated back to the CLI.

3

Thanks for the response. Could you point me to examples or docs that describe/explain this strategy a bit more? I am trying to grok the steps involved and which component (CLI client, SAML provider, Auth0, etc.) is involved.

4

Given that a CLI would fall under the category of native application the recommended flow would be (Call Your API Using the Authorization Code Flow with PKCE). The docs go over each step of the flow and have some code snippets available, however, you would still need to decide how the CLI would handle the redirect response from the system browser. As possible options the CLI could either register a custom URI scheme at the operating system level and use that which would mean the browser redirect to the custom URI would trigger that association or it could also start an HTTP server locally and use a localhost-based redirect URI.

5

Got it. That is very helpful thank you.

6

Just to follow up on this and describe the solution I came up with. This approach did work at least in a test context. I was concerned with the client running a local server since some systems prevent this or prompt the user to “allowing incoming traffic” to the used port.

Since I do have a server involved that is the resource server the user will ultimately be interacting with, the client first sends a request to the server to initiate the flow. It will return a prepared /authorize URL the client will use to open the system browser with. These are:

  • open <url> on macOS
  • xdg-open <url> on Linux
  • cmd /c start <url> on Windows

The redirect_uri parameter in the URL is set to a server endpoint. When the browser tab opens, it will either prompt with the Auth0 dialog or, if an email was provided ahead of time, will route to the specific connection. Once this interaction finishes, the browser will redirect to the server endpoint which returns a snippet of JavaScript in order to close the tab dynamically (Firefox does not allow this so I display a message instead… and I did not test this with IE).

(function() {window.open('', '_self').close();})();

In addition to the authorize URL, the server responds with a token_url which will be used to poll the sever for the resulting access_token once the auth flow finishes.

Since the redirect_uri targets the server, it can do the “code to access token” exchange with Auth0 keeps the Auth0 app client secret private. Once this occurs, the client request with the token_url will return the access token (or in my case a service specific access token).

7

This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.