Intro

This page explains how to use OAuth2.0 Client Credentials grant (defined within the RFC6749) with eduTEAMS.

The Client Credentials grant type in OAuth 2.0 is ideally suited for situations where the application, rather than the user, needs to access the services or data. It's particularly useful for server-to-server interactions where an application needs to access another service on behalf of itself, not on behalf of a particular user.


For more information, please see section 4.4 of the OAuth 2.0 Authorization Framework - RFC6749 specification. 

Please note that the client acts on behalf of itself in this grant, so the access token issued by the Authorization Server reflects the identity of the service account (client) regardless of whether the flow was triggered by the end user's interaction with the client or is a result of client's background processing.

Examples

This section contains some practical examples of where the Client Credentials grant can be effectively utilized along with sequence diagrams depicting the flow.

Background Jobs

Scenario

Applications often run jobs like data synchronization, backups, or batch processing tasks that require access to APIs (other client integrated with eduTEAMS) but are not triggered by a specific user action. The Client Credentials grant provides a way for these jobs to authenticate against the necessary services without requiring user interaction, streamlining automated processes within the application's ecosystem.

Sequence diagram

Aggregated Data Services

Scenario

Services that aggregate data from multiple sources (other clients integrated with eduTEAMS) and provide a unified API to clients can use Client Credentials to authenticate with those sources. This is common in financial services, market data analysis, or news aggregation platforms where the data needs to be fetched regularly and reliably without user involvement.

Sequence diagram

Example requests

Client Credentials flow

Client Credentials grant request
curl -X POST "https://proxy.eduteams.org/OIDC/token" \
     -H "Content-Type: application/x-www-form-urlencoded" \
     -d "grant_type=client_credentials&client_id=<CLIENT_ID>&client_secret=<CLIENT_SECRET>&scope=api"
Client Credentials grant response
{
    "access_token": "eyJhbGciOiJFUzI1NiIs...",
    "token_type": "access_token",
    "scope": "api",
    "expires_in": 3600
}

Token introspection

Token introspection request
curl -X POST "https://proxy.eduteams.org/OIDC/introspect" \
     -H "Authorization: Basic Q0xJRU5UX0lEOkNMSUVOVF9TRUNSRVQ" \
     -H "Content-Type: application/x-www-form-urlencoded" \
     -d "token=eyJhbGciOiJFUzI1NiIs..."
Token introspection response
{
    "active": true,
    "scope": "api",
    "client_id": "<CLIENT_ID>",
    "exp": 1715761201,
    "iat": 1715757600,
    "iss": "https://proxy.eduteams.org",
    "token_type": "Bearer"
}

Support

In order to check whether the Client Credentials grant is supported by the particular instance of the Authorization Server, server metadata needs to be checked.
Although the Client Credentials grant is an OAuth2.0 grant, information on support should be checked in the OpenID Connect Configuration as the Authorization Server is not publishing a separate OAuth2.0 Authorization Server Metadata.

Client Credentials grant is advertised in the metadata by the client_credentials entry in the grant_types_supported property. 

OpenID Connect configuration for eduTEAMs can be found at https://proxy.eduteams.org/.well-known/openid-configuration.

Client registration

Willingness to use the Client Credentials grant needs to be expressed at the moment of registration of the client in the eduTeams Service and for obvious reasons applies only to confidential clients. 

You can find more information about the process of client registration at Registering services on the eduTEAMS Service.

Supported client authentication methods

Currently, only password-based authentication methods are supported (see section 2.3.1 of the OAuth 2.0 Authorization Framework - RFC6749 specification for more details).

References

  • No labels