Matrica
  • Matrica
  • Guides
    • Pricing Guide
    • User Guide
      • Getting Started
      • Linking Wallets
      • Linking Socials
      • Customizing Your Profile
      • Bot Commands
      • Privacy Settings
      • /flash
    • Community Guide
      • Getting Started
      • Manage Community
      • Manage Collections
      • Discord Set-Up
        • Invite the Bot
        • Bot commands
        • Snapshots
      • Verification
        • Adding Rules
        • Fungible Token Roles
        • Amount Based Roles
        • Attribute Based Roles
        • Logic Operators
        • Status Based Roles
        • Verified Collection Roles
        • X Username Gating
        • Wallet Address Gating
        • Validator Stake Gating
        • Inscription # Based Roles
        • Royalty Based Roles
      • Telegram Set-Up
        • Invite the Bot
        • Bot Commands
        • Add Requirements
        • Invite Links
      • Sales Bot and Web-hooks
        • Discord Sales and Listings
        • Telegram Sales
      • Events
        • Create Event
        • Location
        • Requirements
        • Ticketing
      • Proposals
      • Customer Support
      • Staking Support
      • Add-Ons
    • Enterprise
  • Matrica Connect
    • Matrica Connect Overview
    • Who's Building with Matrica Connect?
    • What is OAuth2?
    • Create your application
    • Initial Redirect
    • Retrieving the Access Token
    • API Reference
  • API Reference
    • API - Getting Started
    • Feed
    • User
    • Wallet
    • Events
    • NFT
    • Snapshot
    • Onboard
    • Search
    • Collection
Powered by GitBook
On this page
  • OAuth Roles
  • Implementation at Matrica
  1. Matrica Connect

What is OAuth2?

PreviousWho's Building with Matrica Connect?NextCreate your application

Last updated 1 year ago

OAuth 2.0 is the industry-standard protocol for authorization. OAuth 2.0 focuses on client developer simplicity while providing specific authorization flows for applications.

OAuth Roles

OAuth defines four roles:

  • Resource Owner: The resource owner is the user who authorizes an application to access their account. The application’s access to the user’s account is limited to the scope of the authorization granted (e.g. read or write access)

  • Client: The client is the application that wants to access the user’s account. Before it may do so, it must be authorized by the user, and the authorization must be validated by the API.

  • Resource Server: The resource server hosts the protected user accounts.

  • Authorization Server: The authorization server verifies the identity of the user then issues access tokens to the application.

Implementation at Matrica

We have implemented some OAuth 2.1 specifications (see this ) to have a more secured flow:

  • PKCE is required for all OAuth clients using the authorization code flow

  • Redirect URIs must be compared using exact string matching

  • The Implicit grant (response_type=token) is omitted from this specification

  • The Resource Owner Password Credentials grant is omitted from this specification

  • Bearer token usage omits the use of bearer tokens in the query string of URIs

We will implement the newest standard once it comes out of draft.

link