Authentication

Authentication is how your app learns who is making a request. Authdog runs sign-in, checks the result with the identity provider you configured, and gives your app a session to validate from then on.

Your app never sees the password. It sends the person to Authdog, Authdog finishes the method you enabled, and your backend checks the session on later requests.

To add this to an app, follow Sign up and sign in, or start from a quickstart.

How it works

Your user Selects a sign-in method

Authdog

Creates a trusted session

1 Verify identity 2 Create or link user 3 Issue JWT and cookie

Your app Validates the session

No passwords in your app

That identity is what authorization, organizations, and provisioning build on.

Sign-in methods

Turn on the methods you want in each environment. Only enabled methods show up on that environment's sign-in screen, so development, staging, and production can differ.

• Password. Email and password.
• Social login. OAuth with providers such as Google, GitHub, Microsoft, and Apple. See Integrations.
• Magic link. A one-time link or code sent by email.
• Enterprise SSO. SAML 2.0 or OIDC connections to a customer's identity provider.
• Multi-factor authentication. A second factor, such as TOTP, after the first sign-in succeeds.

Enterprise SSO and domain routing

Add each customer identity provider as a connection on the environment. The connection holds the SAML metadata or the OIDC discovery settings.

Authdog can pick the connection from the user's email domain. Discovery returns the matching connection and a sign-in URL, so you can send them to their company sign-in page without building customer-specific routing in your app.

Request

curl --get "https://identity.authdog.com/api/v1/sso/discover" \
  --data-urlencode "environmentId=<env>" \
  --data-urlencode "[email protected]"

Response

{
  "connectionId": "...",
  "providerId": "okta",
  "signinUrl": "https://identity.authdog.com/..."
}

After sign-in

Once Authdog accepts the sign-in, it:

1. Creates the user, or links the identity to an existing user with the same verified email.
2. Issues a signed JWT in the authdog-session cookie. API clients can send that same token as a bearer token.
3. Sends events such as user.signed_in and user.created to the webhooks and integrations you've configured.

Your backend validates the session on each request. It doesn't check the original credential again. See Sessions and tokens.

Machine-to-machine authentication

Service-to-service calls don't have a person at a browser. An M2M application exchanges a client ID and secret for an access token with the OAuth 2.0 client credentials grant. There's no interactive sign-in, and no session cookie.

Configuration

• Sign-in methods, social providers, and MFA live on the environment.
• Add enterprise SSO connections on the environment, or let customers set them up in the admin portal.
• Use the hosted Account portal, or build the UI with custom flows and components.

Related