Quickstart
This page shows "Sign in with Motaware" as raw HTTP, so you can see every step. In practice, use an OpenID Connect library and point it at the discovery document. It reads every endpoint from there:
https://auth.motaware.com/.well-known/openid-configuration
1. Create a project
In the console, create a project for your product.
All clients in one project see the same user id (sub) for a given person. A web site and a mobile app of the same product belong in one project.
2. Create a client and pick its type
| Type | Use it for | Secret |
|---|---|---|
| Web app (server) | Code that runs on your server: ASP.NET Core, Node, PHP, Python… | Yes |
| Browser app (SPA) | JavaScript that exchanges the code in the browser | No |
| Desktop or mobile app | Installed apps that use the system browser | No |
A web app's client secret is shown once, when it is created or replaced. Store it on your server. Never put it in browser or app code.
3. Register your redirect URL
Add the exact URL Motaware sends people back to after sign-in, for example https://app.example.com/signin-motaware.
URLs are matched exactly: scheme, host, port and path must all be the same. Use https; plain http is accepted only for localhost and 127.0.0.1.
4. Send the person to Motaware
Create a random code_verifier (43–128 characters), and from it a code_challenge: BASE64URL(SHA256(code_verifier)).
PKCE with S256 is required for every client type, web apps included.
Also create a random state and keep it with the verifier until the person comes back.
GET https://auth.motaware.com/connect/authorize
?response_type=code
&client_id=mw_yourclientid
&redirect_uri=https%3A%2F%2Fapp.example.com%2Fsignin-motaware
&scope=openid%20email%20profile
&state=af0ifjsldkj
&nonce=n-0S6_WzA2Mj
&code_challenge=E9Melhoa2OwvFrEMTJguCHaoeK1t8URWbuGJSstw-cM
&code_challenge_method=S256
The person signs in, then sees a consent page that names your app.
If they allow access, Motaware redirects to your URL with ?code=…&state=….
If they cancel, it redirects with ?error=access_denied. Check that state matches the one you stored.
5. Exchange the code
A web app authenticates with its secret, using HTTP Basic or client_secret in the form. Browser and native apps send only client_id.
POST https://auth.motaware.com/connect/token Authorization: Basic base64(client_id:client_secret) Content-Type: application/x-www-form-urlencoded grant_type=authorization_code &code=SplxlOBeZQQYbYS6WxSbIA &redirect_uri=https%3A%2F%2Fapp.example.com%2Fsignin-motaware &code_verifier=dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk
{
"access_token": "eyJhbGciOiJSUzI1NiIs…",
"token_type": "Bearer",
"expires_in": 900,
"id_token": "eyJhbGciOiJSUzI1NiIs…",
"refresh_token": "…" // only when you asked for offline_access
}
6. Read who signed in
Validate the ID token: its signature against the keys at https://auth.motaware.com/.well-known/jwks, then iss, aud (your client id), exp and nonce.
Its claims tell you who signed in. You can also call userinfo with the access token:
GET https://auth.motaware.com/connect/userinfo
Authorization: Bearer eyJhbGciOiJSUzI1NiIs…
{
"sub": "q3Jk0b5Yy0R7m2…",
"email": "ada@example.com",
"email_verified": true,
"name": "Ada Lovelace",
"given_name": "Ada",
"family_name": "Lovelace"
}
Use sub as the user's id in your database, not the email address: people can change their address.
See the reference for token lifetimes, sign-out and errors.