For developers · Platform

Sign in with Auto Secure Login

Q: What does my app receive about the person?

With the openid, email and profile scopes: a stable opaque user ID, the email address, the name and the username. ASL never sends its internal group names to outside apps, and email_verified is always false today.

One account your users already trust, in your app, over standard OpenID Connect.

Give the people who use your app a sign-in that ASL already protects: a password or passkey, 2-step verification and a consent screen that names your app. You add a button and a callback route. ASL handles the rest in English and Spanish.

Get your app registered Read the developer guide

What you get

Sign in with Auto Secure Login: no passwords to store

One account across apps

A person signs in to your app with the same Auto Secure Login account they use for every ASL product, and for any other app that shows the button. One identity, one place to manage it.

2-step verification built in

Every ASL account carries a second step: an email code, a text-message code or a passkey. Your app inherits it on every sign-in without writing any of it.

Consent people can see

The first time, ASL asks the person whether to allow your app, by name, and remembers the answer for four weeks. Nothing is shared with your app until they say yes.

Passkeys and provider accounts

People can create their ASL account with a password or through Google, Microsoft, Apple or GitHub, and sign in with a passkey. Your app sees one ASL identity and never talks to those providers.

Standard OpenID Connect

Authorization code flow with PKCE, discovery document, RS256-signed ID tokens and a JWKS endpoint. Any certified OpenID Connect client library works; there is no SDK to install.

English and Spanish

The sign-in, 2-step and consent screens are offered in both languages, and so is this guide. Your own pages stay yours.

How it works

How OpenID Connect sign-in works for your users

1. They press the button. Your app sends them to ASL's authorize endpoint with a fresh state, nonce and PKCE challenge. The button kit on this page gives you the markup and the mark.

2. They sign in to ASL. Password, passkey or a linked Google, Microsoft, Apple or GitHub account, then their 2-step check. On the first visit ASL asks whether to allow your app.

3. They are back in your app. ASL redirects to your callback with a code. Your server exchanges it for a signed ID token and stores the stable user ID. No password ever touches your system.

If you already run ASL products for your organization, your people sign in to your own tools the same way they sign in everywhere else. The platform overview explains what every ASL product shares.

10 minaccess tokens, so a leaked token is short-lived

30 daysrefresh tokens when you ask for offline access

4 weeksa person's consent to your app is remembered

2languages on every ASL sign-in screen

Who it is for. A web app that wants a sign-in button without running its own password and 2-step system. A mobile, desktop or single-page app that cannot keep a secret and signs in as a public client with PKCE. A tool built for an organization that already uses ASL products.

Get registered

Registration is reviewed by a person, not a form

There is no self-service developer console; a person reviews every registration. Email contact@autosecurelogin.com or use the contact form with three things:

your app's name and the company or person publishing it;
every redirect URI, matched exactly: https:// only, except http://localhost for development;
whether the app can keep a secret (a server-side web app) or not (a mobile, desktop or single-page app, registered as a public client that must use PKCE).

You receive a client ID that starts with asl-ext- and, for server-side apps, a client secret over a private channel. Keep the secret on your server; never ship it in a browser or a mobile app. Tell us when a redirect URI changes. We rotate the secret or disable the app on request.

What your app receives

sub: a stable, opaque user ID. Store this, not the email.
email and email_verified, which is always false today.
name, given_name, family_name, preferred_username, nickname.
A refresh token for 30 days with offline_access.
Never ASL's internal group names, and nothing you did not ask for.

Our privacy policy covers the account; your app's own terms and notice cover what your app does with the claims.

Developer guide

Integrate Sign in with Auto Secure Login

Everything below is standard OpenID Connect. Read the endpoints from the discovery document rather than copying them; it also lists the supported response types, PKCE methods and signing algorithms. In the tables, <slug> stands for your client ID.

Endpoints

Issuer	`https://login.autosecurelogin.com/application/o/<slug>/`
Discovery	`https://login.autosecurelogin.com/application/o/<slug>/.well-known/openid-configuration`
Authorize	`https://login.autosecurelogin.com/application/o/authorize/`
Token	`https://login.autosecurelogin.com/application/o/token/`
UserInfo	`https://login.autosecurelogin.com/application/o/userinfo/`
Keys (JWKS)	`https://login.autosecurelogin.com/application/o/<slug>/jwks/`
Sign-out	`https://login.autosecurelogin.com/application/o/<slug>/end-session/`

Scopes and claims

Scope	What you receive
`openid` (required)	`sub`, a stable, opaque user ID. Store this, not the email.
`email`	`email` and `email_verified`. The flag is currently always `false`; verify the address yourself if you depend on it.
`profile`	`name`, `given_name`, `family_name`, `preferred_username`, `nickname`. Outside apps never receive ASL group names.
`offline_access`	A refresh token, valid 30 days.

Access tokens last 10 minutes. ID tokens are signed with RS256; check the signature against the JWKS endpoint, then iss, aud, exp and your nonce.

The sign-in flow

Send the person to the authorize endpoint with response_type=code, your client_id, redirect_uri, scope=openid email profile, a random state, a random nonce, and a PKCE code_challenge with code_challenge_method=S256. PKCE is required for public clients and recommended for everyone.
The person signs in to ASL in English or Spanish: password, passkey or a linked Google, Microsoft, Apple or GitHub account, plus their 2-step check. ASL asks once whether to allow your app; the answer is remembered for four weeks.
ASL redirects back to your redirect_uri with code and your state. Check state, then POST the code, the same redirect_uri, your code_verifier and your client credentials to the token endpoint.
Validate the ID token. Call UserInfo with the access token if you need the claims again.
To sign the person out of ASL as well as your app, send them to the end_session_endpoint from the discovery document.

A worked example

Suppose ShopCo registers a server-side web app and receives the client ID asl-ext-shopco for the redirect URI https://shop.example.com/auth/callback. Its sign-in link sends the person to https://login.autosecurelogin.com/application/o/authorize/ with these parameters, joined with &:

`client_id`	`asl-ext-shopco`
`redirect_uri`	`https://shop.example.com/auth/callback`, URL-encoded
`response_type`	`code`
`scope`	`openid email profile`
`state`	a random value kept in the person's session
`nonce`	a second random value kept in the session
`code_challenge`	base64url of the SHA-256 of a random `code_verifier`
`code_challenge_method`	`S256`

After the person allows ShopCo, ASL redirects to https://shop.example.com/auth/callback?code=…&state=…. ShopCo's server checks state, then POSTs grant_type=authorization_code, the code, the same redirect_uri, its code_verifier, and its client_id and client_secret to the token endpoint. The response holds the ID token, an access token and, with offline_access, a refresh token. ShopCo stores sub as the account key and shows the person's name.

The button

Use this button, or your own that says Sign in with Auto Secure Login. Point it at your own route that starts the flow. Never link a static page straight to the authorize endpoint, because state, nonce and the PKCE challenge must be fresh for every sign-in.

A preview of the button (not a working sign-in link):

Copy the .asl-signin rules from asl-signin.css into your stylesheet, host a copy of asl-mark.svg, and use this markup with href pointing at your own route:

<a class="asl-signin" href="/auth/asl/login"><img src="/asl-mark.svg" alt="" width="20" height="20"> Sign in with Auto Secure Login</a>

Add asl-signin--light to the class list on a light background. Do not imply that ASL endorses your app, and do not alter the mark.

Rules and limits

Ask only for the scopes you use. Do not share what you receive with third parties without the person's consent, and delete it when they delete their account with you.
ASL can disable an app at any time. That blocks new sign-ins and revokes its tokens.
The sub value is the same for a given person across every outside app, so two apps could match their users. Treat it as personal data.
email_verified is always false today. An app that needs a verified address verifies it itself.
Registration, redirect URI changes, secret rotation and removal are handled by ASL on request; there is no developer console.
Sign-in pages are offered in English and Spanish. Your app's own pages are yours.

The terms of service apply to the ASL account itself, and the security page explains how to report a concern.

Questions developers ask

Sign in with Auto Secure Login: developer questions

Is Sign in with Auto Secure Login a standard OpenID Connect login?

Yes. ASL is an OpenID Connect provider built on the OAuth 2.0 authorization code flow with PKCE, so any certified OpenID Connect client library works. There is no SDK to install.

Do I have to store passwords or run 2-step verification myself?

No. ASL holds the password or passkey, runs the 2-step check and shows the consent screen. Your app receives a signed ID token with a stable user ID, and the claims you asked for.

Can people use a Google, Microsoft, Apple or GitHub account?

Yes. An ASL account can be created with a password or through Google, Microsoft, Apple or GitHub. Either way your app sees one ASL identity and never talks to those providers.

How does an app get registered?

Email contact@autosecurelogin.com with the app name, the publisher, every exact redirect URI and whether the app can keep a secret. Registration is reviewed by a person; there is no self-service console.

What does my app receive about the person?

With the openid, email and profile scopes: a stable opaque user ID, the email address, the name and the username. ASL never sends its internal group names to outside apps, and email_verified is always false today.

Does it work in Spanish?

Yes. The sign-in, 2-step and consent screens are offered in English and Spanish, and this guide exists in both languages.

Put the button in your app.

Send the app name, publisher and redirect URIs, and a person reviews the registration.