Skip to content

oxd 4.0 Documentation#

Attention

Questions and feedback on oxd 4.0 can be directed to Gluu support. View known issues.

Introduction#

oxd exposes simple, static APIs web application developers can use to implement user authentication and authorization against an OAuth 2.0 authorization server like Gluu.

Architecture#

The oxd Linux package includes the oxd-server which is a simple REST application. oxd-server is designed to work over the web (via https), making it possible for many apps across many servers to leverage a central oxd service for OAuth 2.0 security.

oxd saves data in own persistence (h2, redis) and acts as RP for OP. Therefore if client is created by oxd on OP side it is highly recommended to update client's data via oxd API. Otherwise if change client's data by configuring OP directly then data in oxd persistence can be outdated which can lead to confusion.

oxd-https-architecture

Tutorial#

Follow one of our tutorials to learn how oxd works:

Get Started#

To get started:

  1. Install oxd-server

  2. Configure the oxd-server

  3. Start the oxd-server, as described in the installation docs

  4. Call the oxd API to implement authentication and authorization against an external Authorization Server.

API#

oxd implements the OpenID Connect and UMA 2.0 profiles of OAuth 2.0.

Before using oxd API you will need to obtain an access token to secure the interaction with oxd-server. You can follow the two steps below.

  • Register site (returns client_id and client_secret. Make sure the uma_protection scope is present in the request and grant_type has client_credentials value. If add_client_credentials_grant_type_automatically_during_client_registration field in /opt/oxd-server/conf/oxd-server.yml is set to true then client_credentials grant type will be automatically added to clients registered using oxd server.)
  • Get client token (pass client_id and client_secret to obtain access_token. Note if grant_type does not have client_credentials value you will get error to check AS logs.)

Pass the obtained access token in Authorization: Bearer <access_token> header in all future calls to the oxd-server.

oxd API References

OpenID Connect Authentication#

OpenID Connect is a simple identity layer on top of OAuth 2.0.

Technically OpenID Connect is not an authentication protocol--it enables a person to authorize the release of personal information from an "identity provider" to a separate application. In the process of authorizing the release of information, the person is authenticated (if no previous session exists).

Authentication Flow#

oxd supports the OpenID Connect Hybrid Flow and Authorization Code Flow for authentication.

Learn more about authentication flows in the OpenID Connect spec.

oxd Authorization Code Flow#

You can think of the Authorization Code Flow as a three-step process:

UMA 2 Authorization#

UMA 2 is a profile of OAuth 2.0 that defines RESTful, JSON-based, standardized flows and constructs for coordinating the protection of APIs and web resources.

Using oxd, your application can delegate access management decisions, like who can access which resources, from what devices, to a central UMA Authorization Server (AS) like the Gluu AS.

Native Libraries#

oxd APIs are swaggerized! Use the Swagger Code Generator to generate native libraries for your programming language of choice.

For more information about generating native clients, check our FAQ.

Compatibility#

oxd 4.0 has been tested against the following OAuth 2.0 Authorization Servers:

OpenID Providers (OP)#

UMA Authorization Servers (AS)#

Source code#

The oxd source code is available on GitHub.

License#

oxd 4.0 is available under the AGPL open source license.

Support#

Gluu offers support for oxd on the Gluu Support Portal. In fact, we use oxd and a Gluu Server to provide single sign-on across our oxd portal and support app!

For guaranteed response times, private support, and more, Gluu offers VIP support.