Skip to content
DashForDevsDocs
DevelopersHow it works

Identity and sign-in

How people prove who they are, and how every app trusts that.

2 min readUpdated View as Markdown

accounts.dashfordevs.com is the platform's identity provider. Every other app (hub, dashboard, organizations, Cloud, admin) is a relying party that signs people in through it with OpenID Connect.

Signing in to the dashboard
BrowserDashboard serveraccountsopen dashboard1redirect to accounts (PKCE)2password + second factor3redirect back with a one-time code4code5exchange code (client secret)6access + refresh tokens7encrypted session cookie for this host only8

Drag to move · Ctrl/⌘ + scroll to zoom · ← → to step

Overview

Step through it: 4 steps. Click any box for detail.

The rules

  • Access tokens live 10 minutes. Refresh tokens live 30 days and rotate on every use. Reusing an old refresh token revokes the whole family, the signal that one was stolen.
  • Tokens are signed with RS256; public keys are at /.well-known/jwks.json.
  • No token ever reaches browser JavaScript. Every app is a confidential client with a server that holds the tokens.
  • The sign-in cookie lives on accounts.dashfordevs.com only, never on .dashfordevs.com, so a bug on another subdomain cannot steal it.
  • The amr claim says how this session authenticated (for example ["pwd", "otp"]). Sensitive actions check that the session actually passed two-factor, not just that the account has it on.
  • ?next= is allowlisted. After sign-in you return to the app that sent you, if it is a known DashForDevs app; otherwise you land on the hub.
  • Staff always need two-factor, independent of any organization's policy.

Endpoints

Code
GET  /.well-known/openid-configuration
GET  /.well-known/jwks.json
GET  /oauth/authorize
POST /oauth/token
GET  /oauth/userinfo
POST /oauth/revoke

These are for DashForDevs' own apps. Storefronts do not use OIDC; they use API keys.

Keep reading

Something wrong or missing on this page? Email support@dashfordevs.com.