diff --git a/v2/overview/authentication/index.html b/v2/overview/authentication/index.html index c67761d..94359b0 100644 --- a/v2/overview/authentication/index.html +++ b/v2/overview/authentication/index.html @@ -41,7 +41,7 @@

Authentication

  • OAauth2 Authentication
    • -

    Token Authentication

    +

    Token Authentication

    This method is appropriate for API access. It is a secret that is included as a request header.

    Header Format:

    @@ -55,7 +55,7 @@

    Token Authentication

    $ curl -i https://seeclickfix.com/api/v2/profile -H "Authorization: Bearer test-08/12/2024-01/01/2025-xxxxxxxxxxxxxx" -

    OAuth2 Authentication

    +

    OAuth2 Authentication

    This method is appropriate when the client application is being used by multiple users and the user’s credentials should not be shared with the client directly.

    @@ -84,26 +84,25 @@

    OAuth2 Authentication

    With the client id, authentication and API access can proceed as follows using an OAuth Implicit Flow:

      -
    1. Client Application initiates browser access to SCF authentication endpoint
      2. -
    - -
    -https://seeclickfix.com/oauth/authorize?client_id=YOUR_CLIENT_ID&redirect_uri=YOUR_REDIRECT_URI&response_type=token
-
    +
  • +

    Client Application initiates browser access to SCF authentication endpoint

    -
      + 
      + https://seeclickfix.com/oauth/authorize?client_id=YOUR_CLIENT_ID&redirect_uri=YOUR_REDIRECT_URI&response_type=token
+
      +

    1. SCF user enters SCF credentials and on success is redirected to Client Application Redirect URI which will include an access_token

    2. Client Application can now make API requests on behalf of the user, by including user’s access token. See RFC 6750 for options and detail for transmitting the access token to the API endpoints. One method is to send the access_token in the Authentication header:

      + + 
      + Authentication: Bearer xxxxxxxxxxxxxxxxxxxx
+
    -
    -Authentication: Bearer xxxxxxxxxxxxxxxxxxxx
-
    -

    For more details see this overview of the implicit flow RFC 6749, section 4.2

    For additional security we recommend sending a state nonce with the orginal authorize request and verifying that you get it back in the callback. This ensures that the response hasn’t been intercepted by other apps on your mobile device, for example. See this article for more details.