How your application connects to SyAuth
Your application sends users to hosted SyAuth sign-in or calls its authentication API. Your application server uses the resulting identity to establish its own session. The dashboard and management API configure the resources that those authentication flows use.
A developer account signs in to the dashboard and owns or joins workspaces. An application user signs in to your product. Creating one does not create the other.
A workspace groups users and configuration. An OAuth client identifies an application and restricts its redirect URIs, grants and scopes. A workspace may contain several clients; consistently include the intended client when authenticating a user.
A group organizes application users. A workspace's members are other developers who can collaborate on its configuration. Group membership and workspace membership grant different kinds of access.
Your plan determines available features and quotas. Valid credentials do not override resource ownership, token scopes or plan limits. See credentials and resource identifiers.
Terms used in these guides
| Term | What it means here |
|---|---|
| Dashboard | The SyAuth website where you configure workspaces, users and applications |
| OAuth client / application registration | A saved set of login settings, including a client ID and return addresses. Creating it does not build or run an app. |
| Callback / redirect URI | The return address the browser opens after login and approval. An app or the test receiver must receive the result there. |
localhost / 127.0.0.1 | The computer running your browser. A URL using either name needs a program running on that computer. |
| Terminal / command prompt | An application on your computer where you paste and run commands. It is separate from the browser address bar and browser developer console. |
| API request / endpoint | A request a program sends to a service, and the service address that handles it. The curl commands in these docs send those requests. |
| JSON / request body | A text format such as {"email":"[email protected]"}, and the data sent with a request. Example email addresses and placeholders must be replaced. |
| HTTP status | The result number printed by the service: for example, 200 means a request succeeded, 201 means something was created, and 400 means the request was rejected. |
| Token | A credential issued by the service. Different tokens permit different tasks; copy the exact type named by the guide. |
| Scope | A named permission. OAuth client scopes describe access during sign-in; developer-token scopes describe management access. They are configured separately. |
| Session | Saved information linking a browser to a login or a pending login attempt. It can expire even while the user's account still exists. |
| MFA / passkey | An extra sign-in check such as an authenticator code, or a device/browser credential used to prove identity |