Skip to content
  • Our Product
    • Namazu Elements
      • What is Elements?
      • Why open source?
      • Docs
        • Elements in Five Minutes or Less
        • RESTful APIs Library
        • Security Model
        • Accessing the Web UI (CMS)

    Our Product

    A logomark with three layered rhombuses adorning the lettermark that says Elements in bold all-caps sans-serif letters.
    • What is Namazu Elements? Discover our easy-to-use backend network solution built for online games. Rapidly enables full-scale multiplayer games or online solo adventures.
    • Why open source? Is there a truly open source server backend for connected games? There is now. Download and run a local copy of Namazu Elements and try it for yourself.
    Download Namazu Elements

    Get started

    • Quick start Read our Elements 5-minute quick start guide
    • Documentation Read our developer docs for learning more about Elements
    • RESTful APIs A full list of core API specs for working with the Elements framework
    • Security An overview of the server-authoritative security model of Elements
    • Accessing the CMS Manage your game with ease via the Namazu Elements CMS.

    Co-development Reimagined

    • Reduce your costs Would you rather outsource your backend development? Hire Namazu Studios to build your server backend with the power of Namazu Elements.
      Co-dev

    Recent Posts

    • The watercolor-styled Namazu Studios logo over a giant namazu lurking in the depth
      Namazu Studios Featured in San Diego Business Journal
      22 Sep 2025 Press
    • Namazu Elements 3.1 Released – Service Layer Fixes, Secure APIs, and Steam Bug Fix
      22 Apr 2025 Release Notes
  • Case Studies
  • About Us
  • News
  • Services
  • Book a call
namazu-studios-logo
Book a call

Getting Started

  • Elements in Five Minutes or Less
  • Accessing the Web UI (CMS)
  • General Concepts
  • N-Tier Architecture
  • Security Model

Namazu Elements Core

  • User Authentication / Sign In
    • What is a User?
    • User Authentication in Elements
    • Auth Schemes
      • Auth Schemes
      • OAuth2
      • OIDC
  • Features
    • Applications
    • Sessions
    • Users and Profiles
    • Digital Goods
    • Progress and Missions
    • Progress and Missions (3.4+)
    • Leaderboards
    • Matchmaking – Comprehensive Guide
    • Followers
    • Friends
    • Receipts
    • Reward Issuance
    • Save Data
    • Metadata
    • Metadata (3.4+)
    • Queries
    • Web3
      • Wallets
      • Vaults
      • Omni Chain Support
      • Smart Contracts
        • Smart Contracts
  • Queries
    • Advanced Operators
    • Object Graph Navigation
    • Boolean Queries
    • Base Query Syntax
  • Advanced Operators
    • .name
    • .ref

Custom Code

  • Custom Code Overview
  • Windows Setup
  • Mac OS Setup
  • Ubuntu Linux Setup
  • Introduction to Guice and Jakarta in Elements
  • Structuring your Element
  • Packaging an Element with Maven
  • Deploying an Element
  • Preparing for code generation
  • Properties
  • Websockets
  • RESTful APIs
  • Direct MongoDB Access (3.5+)

Releases

  • 3.6 Release Notes
  • 3.5 Release Notes
  • 3.4 Release Notes
  • 3.3 Release Notes
  • 3.2 Release Notes
  • 3.1 Release Notes

Configuration

  • Matchmaking – Comprehensive Guide
  • Direct Database Access and Batch Configuration
  • Batch Samples
    • Mission Upload Bash Script Sample
    • Item Upload Bash Script Sample

RESTful APIs

  • RESTful APIs Library
  • Swagger and Swagger UI

Add-Ons

  • Custom Elements
    • Crossplay
      • Namazu Crossfire (Multiplayer)
      • Deploying Namazu Crossfire in your game
  • Game Engines
    • Unity
      • Elements Codegen
      • Crossfire
    • Roblox
      • Roblox Overview
      • Secure Player Authentication & Registration
      • Global Matchmaking
      • Roblox Security Best Practices

Troubleshooting

  • Common Issues with Docker
  • Local SDK
    • Unable to deploy application : dev.getelements.elements.sdk.exception.SdkElementNotFoundException
    • Could not load class : java.lang.NoClassDefFoundError
  • Namazu Elements Community Edition
    • Common Issues with Docker
    • Unable to deploy application : dev.getelements.elements.sdk.exception.SdkElementNotFoundException
View Categories
  • Home
  • Docs
  • Namazu Elements Core
  • User Authentication / Sign In
  • Auth Schemes
  • OAuth2

OAuth2

Est. read time: 4 min read


When creating a new Session, you have the option to authenticate using a predefined OAuth2 Auth Scheme. #

OAuth2 Auth Scheme Anatomy #

OAuth2 Auth Schemes are comprised of:

  • the Scheme name
  • a Validation URL, which Elements will use to validate the token it receives
  • the Response Id Mapping, which Elements will use to get the user id from the validation request (see below for example)
  • a list of Headers and a list of Parameters for the validation request, which can be predefined, or sent from the client and filled in by Elements before making the validation request

Since the requirements for OAuth2 vary by provider, we’ve created a system that is flexible enough for any spec. For instance, some systems, such as Oculus, require that you send the user id from the client alongside the validation token. We’ve added a User Id flag that allows you to flag either a header, parameter, or body property as the User Id (only one is allowed) in these instances. In other cases, the user id comes back in the response when validating the token. In these cases, we’ve provided an id mapper. In any case, it’s very important to look at the docs for the oauth provider and understand exactly what they’re expecting.

Once the validation request comes back successfully, Elements will link the provided/returned user id to the internal Elements user id.

Auth Scheme Properties #

Here’s a breakdown of the auth scheme properties and what they represent:

IdThe Elements database id.
NameThe unique name of this scheme in the Elements system.
Validation UrlThe URL that the server to server validation request will be sent to.
HeadersAny headers that the validation request might be expecting. Can mark as fromClient, indicating that this will be sent from the client. Otherwise, it assumes that this was predefined in the auth scheme.
ParamsAny query parameters that the validation request might be expecting. Can mark as fromClient, indicating that this will be sent from the client. Otherwise, it assumes that this was predefined in the auth scheme.
Body(POST requests only) Any body parameters that the validation request might be expecting. Can mark as fromClient, indicating that this will be sent from the client. Otherwise, it assumes that this was predefined in the auth scheme.
Response Id MappingDetermines how to map the user id in the response. Will search the response for the corresponding key. For example, if the response is structured like:
{“response”: { “params” : { “steamid” : <id> } } }
then you only need to input “steamid”. Ignored if one of the parameters is marked as user id.
Response Valid MappingOptional key in the response whose value indicates whether the token/user is valid.
For example: “is_valid”, “active”, or “success”.
If not set, only the HTTP status code is used.
Response Valid Expected ValueOptional expected value for the validation field.
If null:
– boolean true is treated as success
– non-empty/non-null for non-boolean values is treated as success.
If set, the field’s string value must equal this.
Valid Status CodesHTTP status codes that are considered “processable” for validation.
Any other status is treated as failure before inspecting the body.
Defaults to [200].
MethodHTTP method for the validation request (GET or POST).
Body TypeHow to encode the request body when using POST.
FORM_URL_ENCODED corresponds to application/x-www-form-urlencoded.

Steam Example #

One of the default OAuth2 Auth Schemes is for authenticating via Steam. We’ll use this as an example as to how these can be used.

Note

It will be necessary to have a registered application on Steam, as this process will require an application id.

The goal here is to have our client application retrieve an auth ticket from Steam, then to send that to Elements, which in turn will use the ticket to verify the corresponding user id.

Note

This assumes that you already have a process set up to retrieve the auth ticket, either manually as depicted in the Steam documentation, or through a client library, such as Steamworks.net.

First let’s look at the auth scheme to determine what Elements is expecting:

{
  "id": "683a2311bc53452f7ea04b33",
  "name": "Steam",
  "validationUrl": "https://api.steampowered.com/ISteamUserAuth/AuthenticateUserTicket/v1/",
  "headers": [
    {
      "key": "x-webapi-key",
      "value": "169AA59968B1FDBA0E303C311C525B8F",
      "fromClient": false,
      "userId": false
    },
    {
      "key": "Content-Type",
      "value": "application/x-www-form-urlencoded",
      "fromClient": false,
      "userId": false
    }
  ],
  "params": [
    {
      "key": "appid",
      "value": "370140",
      "fromClient": false,
      "userId": false
    },
    {
      "key": "ticket",
      "value": "Ticket from GetAuthSessionTicket (Sent from frontend)",
      "fromClient": true,
      "userId": false
    },
    {
      "key": "identity",
      "value": "nebtest",
      "fromClient": false,
      "userId": false
    }
  ],
  "responseIdMapping": "steamid",
  "validStatusCodes": [
    200
  ]
}

We’re basically telling it how to format the request that Elements will send to the authenticating server. In this case, we’re telling Elements to expect the ticket to be sent from the client (the only header or parameter with fromClient as true), and that all other values will be preset in the scheme and stored within Elements.

Note

When you make the call to GetAuthTicketForWebApi to retrieve the auth ticket, you pass in an identity value. This can be anything (or nothing), but must match on the client and server side.

When we make a request against the /auth/oauth2 endpoint, Elements will format a new request using the headers and params information in the scheme, and will send the request to the validationUrl defined in the scheme. In this case, we only told the scheme to expect one parameter, "ticket", and no headers from the client, so our request would look like this:

Example: 
POST http://localhost:8080/api/rest/auth/oauth2

Body:
{
    "schemeId":"Steam",
    "requestParameters" : {
        "ticket":"<Your Steam ticket from GetAuthTicketForWebApi call. Will be very long, around 5120 characters.>""
    }
}

When Elements receives the response, it will use the responseIdMapping to look for a corresponding key, and will assume the value of this key is the user’s id.

Example response from Steam (handled internally in Elements):
{
    "response": {
        "params": {
            "result": "OK",
            "steamid": "<steam user id>",
            "ownersteamid": "<steam user id>",
            "vacbanned": false,
            "publisherbanned": false
        }
    }
}

If Elements retrieves the user id successfully, it will automatically associate this Steam user id with an Elements user, and return the Elements Session object back to you.

Once you have the Session object, just add the sessionSecret to the Elements-SessionSecret header for subsequent requests, and you’re all set!

What are your Feelings
Still stuck? How can we help?

How can we help?

Updated on January 30, 2026
OIDC
Table of Contents
  • When creating a new Session, you have the option to authenticate using a predefined OAuth2 Auth Scheme.
  • OAuth2 Auth Scheme Anatomy
  • Auth Scheme Properties
  • Steam Example
  • Documentation
  • Terms of Service
  • Privacy Policy
  • Contact us
  • Linkedin
  • Join our Discord

Namazu Studios LLC is powered by Namazu Elements, an Elemental Computing Inc. product.

Elements
  • Download
  • About Elements
  • Open source
  • Documentation
  • Support
About Namazu
  • Case Studies
  • About Us
  • News
Get in Touch
  • info@namazustudios.com
  • Book a call
  • (619) 862-2890
  • Linkedin
  • Discord

©2008-2025 Namazu Studios. All Rights Reserved.