Skip to content

Authentication

The auth flow is following

  1. a customer enters an email
  2. a client app sends a POST request to /v1/auth/by-link/link/ with payload
    {
        "email": "the customer email"
    }
    
  3. the API sends an email message to the received email address with a link https://frontend.app/auth/link/{token} (the address can be changed by request to the backend team).
    If you're working with a dev server (not a production one), the API adds _debug_auth_link key to the response that contains the link. Email may not be sent by the dev versions of the API.
  4. The customer clicks the link from the email
  5. the client has to get the token from the url and obtain an auth token sending POST request to /v1/auth/by-link/login/ with payload
    {
        "token": "the token from url",
        "client_key": "client key here"
    }
    
    Ask the backend team for detailed info about client_key.
  6. If the token is valid, API return auth token and the user data:
    {
        "token": "the auth token",
        ...
    }
    
  7. You need to store the auth token on client-side and send the token with every request in the Authorization http header in the following format:
    Authorization: Token {the auth token}
    

If the auth token you send to /v1/auth/by-link/login/ is invalid, you'll get http 400 error.

Social OAuth 2

The auth flow is following

  1. Front-end need to know following params for each social provider:

    • client_id # only in case of OAuth 2.0, id of registered application on social service provider
    • redirect_uri # to this url social provider will redirect with code
    • scope=your_scope # for example email
    • response_type=code # same for all oauth2.0 providers
  2. Front-end redirect user to social authorize url with params from previous point.

  3. User confirms.

  4. Social provider redirects back to redirect_uri with param code.

  5. Front-end now ready to login the user. To do it, send POST request with provider name and code:

    POST v1/auth/social/login/
    

    with data (form data or json)

    {
        "provider": "google-oauth2",
        "code": "AQBPBBTjbdnehj51",
        "client_key": "client key here",
        "redirect_uri": "absolute redirect uri here"
    }
    

    Backend will either signin the user, either signup, either return error.
    Ask the backend team for detailed info about client_key.

    Sometimes it is more suitable to specify provider in url, not in request body. It is possible, the API will understand that. Following request is the same as above:

    POST v1/auth/social/login/google-oauth2/
    

    with data (form data or json)

    {
        "code": "AQBPBBTjbdnehj51",
        "client_key": "client key here",
        "redirect_uri": "absolute redirect uri here"
    }