Social.Live
  • Introduction
    • Why Social.Live?
    • What is it aiming for?
    • What are the use cases?
  • Architecture
    • Social Oracle
      • How does it work?
      • How can I become an Oracle node?
    • SocialPASS
    • LiveCAST
    • Chat3.one
      • Full social functions
      • How better than others
  • How does social incubation work?
  • API/SDK
    • One-on-One Video/Audio Calls
      • Create App
      • Voice/Video Calling
    • Messaging
    • Lucky Wheel
    • Social Login
      • Login Methods
        • OAuth
      • Authentication
        • Authorization
Powered by GitBook
On this page
  1. API/SDK
  2. Social Login
  3. Authentication

Authorization

PreviousAuthentication

Last updated 7 months ago

When a user logs in to your app and becomes authenticated, SocialLive issues the user an app access token. This token is signed by SocialLive and cannot be spoofed.

When your frontend makes a request to your backend, you should include the current user's access token in the request. This allows your server to determine whether the requesting user is truly authenticated or not.

Access token format

SocialLive access tokens are , signed with the EdDSA algorithm. These JWTs include certain information about the user in its claims, namely:

  • sid is the user’s current session ID

  • sub is the user’s SocialLive ID

  • iss is the token issuer, which should always be auth.social.live

  • aud is your SocialLive app ID

  • iat is the timestamp of when the JWT was issued

  • exp is the timestamp of when the JWT will expire and is no longer valid. This is generally 30 minutes after the JWT was issued.

JSON Web Tokens (JWT)