Mastering the ClassLink Authorization Endpoint

In the rapidly evolving landscape of educational technology, seamless and secure data exchange is not merely a convenience but a foundational requirement. Schools, districts, and technology providers rely on robust integration methods to connect disparate systems, from student information systems (SIS) and learning management systems (LMS) to countless educational applications. At the heart of many such integrations, particularly within the K-12 sector, lies ClassLink, a pivotal platform designed to simplify access and manage rostering. For developers and IT professionals seeking to build resilient and secure applications that interact with ClassLink, mastering its Authorization Endpoint is an indispensable skill. This comprehensive guide will meticulously explore every facet of the ClassLink Authorization Endpoint, delving into the underlying protocols, best practices, security considerations, and advanced integration strategies necessary to achieve a truly optimized and secure educational ecosystem.

The journey into secure integration begins with a profound understanding of authorization mechanisms. In an age where data privacy and security are paramount, particularly when dealing with sensitive student and educator information, merely authenticating a user is insufficient. True mastery lies in understanding what data an application is permitted to access and how that permission is granted and managed. The ClassLink Authorization Endpoint serves as the critical initial gateway in this process, orchestrating the delegation of limited access from a resource owner (the user) to a client application, without ever exposing the user's credentials directly to the client. This intricate dance of permissions, protocols, and parameters forms the bedrock of secure EdTech integrations, demanding precision and adherence to industry-standard security practices.

Understanding ClassLink and Its Ecosystem

Before we dissect the intricacies of the Authorization Endpoint, it's crucial to establish a firm understanding of ClassLink itself and its vital role within the educational technology landscape. ClassLink is far more than just a single sign-on (SSO) portal; it’s an expansive platform designed to simplify access, analytics, and rostering for students, teachers, and administrators. Its mission is to connect users to their learning resources quickly and securely, while also enabling educational institutions to manage their digital ecosystems effectively.

At its core, ClassLink addresses several critical pain points experienced by K-12 districts. Firstly, the proliferation of digital learning tools often leads to "login fatigue," where users must remember countless usernames and passwords. ClassLink LaunchPad provides a unified portal, offering single sign-on capabilities to hundreds of applications, drastically improving the user experience and reducing helpdesk calls. Secondly, managing student and teacher accounts across various systems, a process known as rostering, is traditionally manual, error-prone, and time-consuming. ClassLink Roster Server automates this process by securely pulling data from the Student Information System (SIS) and distributing it to connected applications in a standardized format, typically OneRoster API specifications. Finally, ClassLink OneSync is a powerful identity management solution that automates account provisioning and de-provisioning, ensuring that user accounts are created, updated, and removed across all integrated systems as students and staff join or leave the district.

The broader context of APIs (api) in educational technology cannot be overstated. APIs are the silent workhorses that enable these complex systems to communicate, share data, and function harmoniously. ClassLink leverages a sophisticated array of APIs, including those for rostering, authentication, and user provisioning, to achieve its integration goals. For developers, this means that every interaction with ClassLink, whether it's retrieving a student roster or authenticating a user, typically involves engaging with one or more of its designated API endpoints. This reliance on APIs underscores the importance of understanding the underlying api protocols and security measures, especially the initial steps of obtaining authorization, which is precisely where the Authorization Endpoint comes into play. Without a secure and reliable authorization mechanism, the entire edifice of interconnected EdTech applications risks vulnerability and inefficiency, undermining the very trust that educational institutions place in these technologies.

The Fundamentals of OAuth 2.0 and OpenID Connect (OIDC)

To truly master the ClassLink Authorization Endpoint, one must first grasp the foundational protocols upon which it is built: OAuth 2.0 and OpenID Connect (OIDC). These standards are not merely technical specifications; they represent a paradigm shift in how applications handle user authentication and authorization, moving away from dangerous practices of sharing credentials to a secure, token-based delegation model. ClassLink, like most modern and secure platforms, leverages these protocols to ensure both robust security and a streamlined user experience.

OAuth 2.0: Delegation of Authorization

OAuth 2.0 is an authorization framework that enables an application (the "client") to obtain limited access to an HTTP service (the "resource server") on behalf of a user (the "resource owner"). Crucially, it achieves this without ever revealing the user's credentials to the client application. Instead, it relies on an "authorization server" (in our case, ClassLink) to mediate the process and issue "access tokens."

Let's break down the key roles in OAuth 2.0: * Resource Owner: This is typically the end-user (e.g., a student or teacher) who owns the data being protected and grants permission for an application to access it. * Client: This is the application requesting access to the resource owner's protected resources. It could be a web application, a mobile app, or a desktop application. * Authorization Server: This server is responsible for authenticating the resource owner and, if consent is given, issuing an access token to the client. ClassLink acts as the authorization server in this context. * Resource Server: This server hosts the protected resources (e.g., ClassLink Roster Server apis containing student data). It accepts access tokens and validates them before granting access to the requested resources.

The core concept of OAuth 2.0 is authorization, not authentication. It answers the question: "Is this application allowed to access this user's data?" It does not inherently answer: "Who is this user?" That's where OpenID Connect steps in.

OpenID Connect (OIDC): An Identity Layer on OAuth 2.0

OpenID Connect is a simple identity layer built on top of the OAuth 2.0 framework. While OAuth 2.0 provides authorization, OIDC provides authentication, allowing clients to verify the identity of the end-user based on the authentication performed by an authorization server, as well as to obtain basic profile information about the end-user. Essentially, OIDC leverages OAuth 2.0's secure communication channels to transmit identity information.

The key addition in OIDC is the ID Token. This is a JSON Web Token (JWT) that contains claims about the authentication event and the user, such as their unique identifier (sub), name, email, and other profile details. The ID Token is digitally signed by the authorization server, allowing the client to verify its authenticity and integrity.

The Authorization Code Grant Flow (Most Relevant for ClassLink)

Among the various OAuth 2.0 grant types, the Authorization Code Grant is the most secure and widely recommended for web applications, and it is the primary flow employed by ClassLink. This flow is designed to protect the client secret (if applicable) and to prevent direct credential exposure.

Here's a high-level overview of the Authorization Code Grant flow: 1. Client initiates authorization request: The client application redirects the user's browser to the ClassLink Authorization Endpoint, including various parameters like client_id, redirect_uri, scope, and state. 2. User authentication and consent: ClassLink prompts the user to log in (if they aren't already) and then asks for their consent to allow the client application to access the requested data (based on the scope). 3. Authorization Code issued: If the user approves, ClassLink redirects the user's browser back to the redirect_uri specified by the client, appending a short-lived "authorization code" to the URL. 4. Client exchanges code for tokens: The client application, receiving the authorization code, makes a direct, backend-to-backend request to ClassLink's Token Endpoint. This request includes the authorization code, its client_id, and its client_secret (if applicable), alongside the redirect_uri. 5. Tokens issued: ClassLink's Token Endpoint validates the request and, if valid, issues an access_token (for accessing protected resources) and an id_token (for user identity information, as per OIDC). It may also issue a refresh_token for obtaining new access tokens without user re-authentication. 6. Client accesses resources: The client uses the access_token to make authenticated requests to ClassLink's Resource Server (apis) to retrieve user data or perform authorized actions.

Key Components

Several essential components facilitate these protocols: * Client ID: A unique public identifier for your application, registered with ClassLink. * Client Secret: A confidential secret known only to your application and ClassLink, used for authentication at the Token Endpoint (for confidential clients). * Redirect URI: The URL where ClassLink will redirect the user's browser after successful (or failed) authorization. It must be pre-registered with ClassLink for security. * Scopes: Strings that define the specific permissions or access rights an application is requesting (e.g., openid, profile, roster.users.read). * State: An opaque value used by the client to maintain state between the request and the callback. Crucially, it protects against Cross-Site Request Forgery (CSRF) attacks. * PKCE (Proof Key for Code Exchange): An extension to the Authorization Code Grant flow designed to protect public clients (like mobile apps or SPAs) from authorization code interception attacks. It involves a code_verifier generated by the client and a code_challenge derived from it, sent to the Authorization Endpoint. The code_verifier is then used at the Token Endpoint.

Understanding these fundamentals is paramount. Each parameter and flow step serves a specific security or functional purpose, and their correct implementation is non-negotiable for building secure and compliant applications within the ClassLink ecosystem.

Dissecting the ClassLink Authorization Endpoint

The ClassLink Authorization Endpoint is the initial point of contact for any application seeking to authenticate a user and obtain their consent to access protected resources. It's where the journey of secure data integration begins, making its precise understanding and correct implementation absolutely critical. This endpoint orchestrates the user's interaction with ClassLink's authentication system and facilitates the initial hand-off of an authorization code back to your application.

Purpose and Function

The primary purpose of the ClassLink Authorization Endpoint is twofold: 1. Authenticate the Resource Owner: It directs the user to ClassLink's login page, where they authenticate using their ClassLink credentials (or through federated identity providers linked to ClassLink). 2. Obtain Consent for Resource Access: Once authenticated, ClassLink presents the user with a consent screen (if required by the requested scopes or if it's the first time the application is requesting these permissions) detailing the data the client application wishes to access. Upon user approval, the authorization process can proceed.

Upon successful authentication and consent, the Authorization Endpoint generates a temporary authorization code and redirects the user's browser back to a pre-registered redirect_uri on the client application, appending this code (along with the state parameter) to the URL. This code is not an access token itself; rather, it's a single-use credential that the client application will then exchange for actual access and ID tokens at ClassLink's Token Endpoint.

URL Structure and Common Parameters

The ClassLink Authorization Endpoint typically follows a standard OAuth 2.0/OIDC pattern. The base URL will vary depending on the ClassLink instance or environment, but it generally looks something like https://launchpad.classlink.com/oauth2/v2/auth or https://login.classlink.com/oauth2/auth. It is imperative to consult ClassLink's official developer documentation for the precise base URL for your integration.

To initiate the authorization flow, your application will construct a URL by appending a series of query parameters to this base URL. The request is made via an HTTP GET method, and the user's browser is redirected to this constructed URL.

Let's meticulously detail the essential parameters:

Required Parameters:

1. response_type (Required)
   • Description: Specifies the desired grant type. For the Authorization Code Grant flow, which is standard for ClassLink, this value should almost always be code. If you are also requesting an ID Token (which you will be with OIDC), it is commonly code id_token or code token but usually code for the authorization code flow followed by a token exchange. For ClassLink, code is typically sufficient here, as id_token and access_token are retrieved from the Token Endpoint.
   • Example Value: code
   • Notes: Using code is the most secure method as it keeps tokens out of the browser history and requires a backend exchange, protecting the client secret.
2. client_id (Required)
   • Description: A unique identifier that ClassLink assigns to your application when you register it. This identifies your application to ClassLink.
   • Example Value: your_registered_client_id
   • Notes: This is a public identifier and does not need to be kept secret. It allows ClassLink to verify that the request is coming from a known application.
3. redirect_uri (Required)
   • Description: The URL to which ClassLink will redirect the user's browser after they have authenticated and granted (or denied) consent. This URL must be pre-registered and whitelisted with ClassLink for security reasons.
   • Example Value: https://your-app.com/auth/callback
   • Notes: This is a critical security parameter. ClassLink will only redirect to a URI that has been explicitly registered. Any mismatch will result in an error. Ensure this endpoint on your application is ready to handle the incoming authorization code and state parameter.
4. scope (Required)
   • Description: A space-separated list of scopes (permissions) that your application is requesting. These scopes define the specific resources or user information your application needs access to.
   • Example Value: openid profile email roster.users.basic
   • Notes: Always include openid if you intend to use OpenID Connect for identity verification. Other scopes grant access to specific ClassLink resources (e.g., profile for basic user profile, email for email address, roster.users.basic for basic roster user data). Request only the minimum necessary scopes, adhering to the principle of least privilege.
5. state (Required)
   • Description: An opaque value used by the client to maintain state between the request and the callback. ClassLink will return this exact value unmodified in the redirect to the redirect_uri.
   • Example Value: aRandomStringOnlyYourAppKnows
   • Notes: This parameter is crucial for security, primarily to mitigate Cross-Site Request Forgery (CSRF) attacks. Your application should generate a cryptographically secure random value, store it in the user's session, and verify that the state parameter received in the callback matches the one sent. If they don't match, the request should be rejected.

Optional/Recommended Parameters:

1. prompt (Optional)
   • Description: Specifies whether the authorization server should prompt the user for reauthentication or consent.
   • Example Values:
     • none: The authorization server MUST NOT display any authentication or consent user interface. Useful for checking existing authentication status. If the user is not authenticated or consent is needed, an error is returned.
     • login: The authorization server SHOULD prompt the user for reauthentication, even if they are already logged in.
     • consent: The authorization server SHOULD prompt the user for consent, even if they have previously granted consent to the client for the requested scopes.
   • Notes: Using prompt=none can be useful for silent authentication checks, but developers must be prepared to handle the interaction_required or login_required error responses.
2. login_hint (Optional)
   • Description: A hint to the authorization server about the login identifier the user might use. This can pre-fill the username field on the login page.
   • Example Value: student_id@schooldistrict.org
   • Notes: While useful for user experience, it's not a security parameter. It's often used when an application already knows the user's identifier from a previous session or context.
3. nonce (Optional, Recommended for OIDC)
   • Description: A string value used to associate a client session with an ID Token and to mitigate replay attacks. ClassLink will include this value in the ID Token if received.
   • Example Value: anotherRandomString
   • Notes: When present, your client application should store this value and verify that the nonce claim in the received ID Token matches the nonce sent in the authorization request. This provides an additional layer of security for OpenID Connect flows.
4. code_challenge (Optional, Required with PKCE)
   • Description: A cryptographically secure hash of the code_verifier, used in the Proof Key for Code Exchange (PKCE) flow.
   • Example Value: E9MelhnFfBLw5w8fZM9ttzitGHdnyzGpqGEHw9QDl6w (SHA256 hash of a code_verifier)
   • Notes: PKCE is highly recommended, especially for public clients (e.g., single-page applications, mobile apps) where a client_secret cannot be securely stored. The code_verifier is a random string generated by the client, and the code_challenge is derived from it.
5. code_challenge_method (Optional, Required with PKCE)
   • Description: The method used to derive the code_challenge from the code_verifier.
   • Example Value: S256
   • Notes: The S256 method (SHA256 hash) is the only one recommended and supported for PKCE.

Example Authorization Request (Conceptual):

GET https://launchpad.classlink.com/oauth2/v2/auth?
response_type=code&
client_id=your_registered_client_id&
redirect_uri=https%3A%2F%2Fyour-app.com%2Fauth%2Fcallback&
scope=openid%20profile%20email%20roster.users.basic&
state=aRandomStringOnlyYourAppKnows&
code_challenge=E9MelhnFfBLw5w8fZM9ttzitGHdnyzGpqGEHw9QDl6w&
code_challenge_method=S256

(Note: parameters should be URL-encoded in a real request.)

This URL, when opened in a user's browser, initiates the entire authorization flow, directing the user to ClassLink, managing their authentication, seeking their consent, and finally redirecting them back to your application with the essential authorization code. The meticulous construction of this URL, with careful attention to each parameter, is the first and most crucial step in a secure and functional ClassLink integration.

The Authorization Code Grant Flow with ClassLink

The Authorization Code Grant flow is the most secure and recommended method for client applications, particularly web apis, to interact with ClassLink. It is designed to prevent direct credential exposure and ensure that sensitive tokens are exchanged over secure backend channels. Let's walk through this multi-step process, focusing on the interactions with the ClassLink Authorization Endpoint.

Step-by-Step Walkthrough

1. Client Initiates Request to Authorization Endpoint: The user, through their web browser, attempts to access a protected resource or log into your client application. Your application detects that the user is not authenticated or authorized and initiates the OAuth 2.0/OIDC flow. It constructs a URL for the ClassLink Authorization Endpoint, including all necessary parameters: response_type=code, client_id, redirect_uri, scope, and a securely generated state parameter. If PKCE is being used (highly recommended), code_challenge and code_challenge_method are also included. Your application then redirects the user's browser to this constructed URL.

Example Client-side Redirect:

// In your client-side code (or server-side generating the redirect)
const authorizationEndpoint = 'https://launchpad.classlink.com/oauth2/v2/auth';
const clientId = 'your_registered_client_id';
const redirectUri = encodeURIComponent('https://your-app.com/auth/callback');
const scope = encodeURIComponent('openid profile email roster.users.basic');
const state = generateRandomString(32); // Store this in session!
const codeVerifier = generateRandomString(128); // For PKCE
const codeChallenge = base64URLEncode(sha256(codeVerifier)); // For PKCE

localStorage.setItem('oauth_state', state); // Store state in session or local storage
localStorage.setItem('pkce_code_verifier', codeVerifier); // Store verifier

const authUrl = `${authorizationEndpoint}?` +
                `response_type=code&` +
                `client_id=${clientId}&` +
                `redirect_uri=${redirectUri}&` +
                `scope=${scope}&` +
                `state=${state}&` +
                `code_challenge=${codeChallenge}&` +
                `code_challenge_method=S256`;

window.location.href = authUrl;

2. User Authentication and Consent (ClassLink Login Page): Upon redirection, the user's browser arrives at the ClassLink login page (if they are not already logged in). Here, the user provides their ClassLink credentials (username and password). ClassLink authenticates the user. After successful authentication, if it's the first time the application has requested the specified scopes, or if prompt=consent was included in the request, ClassLink will display a consent screen. This screen informs the user about the specific information and permissions your application is requesting (e.g., "This application wants to view your profile, email, and basic roster information"). The user then has the option to grant or deny these permissions.

3. ClassLink Redirects Back to Client with code: If the user successfully authenticates and grants consent, ClassLink generates a one-time use authorization code. It then redirects the user's browser back to the redirect_uri that your application specified in the initial request. The authorization code and the state parameter are appended as query parameters to this redirect_uri.

Example Redirect from ClassLink:

https://your-app.com/auth/callback?code=AUTH_CODE_FROM_CLASSLINK&state=aRandomStringOnlyYourAppKnows

4. Client Exchanges code for access_token and id_token at Token Endpoint: This is a critical backend-to-backend step. When your redirect_uri endpoint receives the authorization code, your application must immediately perform several actions: * Validate state: Compare the state parameter received in the callback URL with the state value stored in the user's session (or local storage). If they do not match, the request is a potential CSRF attack and must be rejected. * Make a POST request to ClassLink's Token Endpoint: Your application makes a direct, server-to-server HTTP POST request to ClassLink's Token Endpoint. This request includes: * grant_type=authorization_code * code: The authorization code received from the Authorization Endpoint. * client_id: Your application's client ID. * client_secret: Your application's client secret (for confidential clients). * redirect_uri: The same redirect_uri used in the initial authorization request. * code_verifier: The cryptographically random string generated in Step 1 (if PKCE was used).

Example Token Exchange Request (Server-side):

POST /oauth2/v2/token HTTP/1.1
Host: launchpad.classlink.com
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code&
code=AUTH_CODE_FROM_CLASSLINK&
client_id=your_registered_client_id&
client_secret=your_client_secret&
redirect_uri=https%3A%2F%2Fyour-app.com%2Fauth%2Fcallback&
code_verifier=the_original_code_verifier_string

5. ClassLink Issues Tokens: If the request to the Token Endpoint is valid (i.e., the authorization code is correct and hasn't expired, client_id, client_secret, redirect_uri, and code_verifier all match), ClassLink's Token Endpoint responds with a JSON object containing: * access_token: A token that grants access to specific ClassLink apis (Resource Servers) on behalf of the user. This token has a limited lifespan. * id_token: (If openid scope was requested) A JWT containing claims about the authenticated user's identity. * token_type: The type of token (e.g., Bearer). * expires_in: The lifespan of the access_token in seconds. * refresh_token: (Optional) A long-lived token that can be used to obtain new access_tokens without requiring the user to re-authenticate (for confidential clients).

Example Token Response:

{
  "access_token": "ACCESS_TOKEN_STRING",
  "id_token": "ID_TOKEN_JWT_STRING",
  "token_type": "Bearer",
  "expires_in": 3600,
  "refresh_token": "REFRESH_TOKEN_STRING"
}

6. Client Uses Tokens to Access User Data: With the access_token, your application can now make authenticated requests to ClassLink's various apis (e.g., Roster Server API, User API) to retrieve the user's roster data, profile information, or other authorized resources. The access_token is included in the Authorization header of subsequent API requests as a Bearer token. The id_token can be used to verify the user's identity and extract basic profile information directly within your application, following OIDC best practices for JWT validation (signature verification, expiry, issuer, audience, nonce check, etc.).

Error Handling

Robust error handling is paramount. When things go wrong at the Authorization Endpoint, ClassLink will redirect back to your redirect_uri with error parameters instead of an authorization code. Common error responses in the redirect URL might include: * error=access_denied: The user explicitly denied the authorization request. * error=unauthorized_client: The client_id is invalid or not authorized to use the requested response_type. * error=invalid_scope: The requested scope is unknown, malformed, or exceeds the client's granted capabilities. * error=invalid_request: A required parameter is missing, or a parameter is malformed. * error=server_error: An unexpected error occurred on ClassLink's side. * error=temporarily_unavailable: The authorization server is temporarily down.

Your redirect_uri endpoint must be prepared to parse these error parameters and provide a meaningful experience to the user (e.g., "Login failed: You denied access to the application," or "An unexpected error occurred. Please try again."). Never expose raw error messages from the authorization server directly to the end-user.

Security Considerations

The Authorization Code Grant flow, especially with PKCE, offers significant security advantages: * Protection of Client Secret: The client_secret is only exchanged in a direct, secure backend channel between your application server and ClassLink's Token Endpoint, never exposed in the user's browser. * Prevention of Authorization Code Interception (with PKCE): PKCE adds a layer of protection against an attacker intercepting the authorization code in transit to a public client and exchanging it for tokens. * CSRF Protection with state: The state parameter prevents attackers from tricking a user into initiating an authorization flow with an attacker-controlled redirect_uri. * Secure Redirect URIs: Whitelisting redirect_uris ensures that ClassLink only redirects authorization codes to trusted locations. This is a critical defense against open redirect vulnerabilities.

Mastering this flow requires not just understanding the steps but also implementing them with rigorous attention to security. Each parameter and interaction point has potential vulnerabilities if not handled correctly, emphasizing the need for diligent development and testing.

APIPark is a high-performance AI gateway that allows you to securely access the most comprehensive LLM APIs globally on the APIPark platform, including OpenAI, Anthropic, Mistral, Llama2, Google Gemini, and more.Try APIPark now! 👇👇👇

Scopes and Permissions in ClassLink

In the world of api integrations, the concept of "scopes" is fundamental to achieving granular control over data access. Scopes act as predefined permissions, allowing client applications to request specific sets of user data or functionalities from a resource server like ClassLink. They embody the principle of least privilege, ensuring that an application only gains access to the information absolutely necessary for its intended function, thereby enhancing security and user privacy.

What are Scopes?

Scopes are string values defined by the authorization server (ClassLink in this context) that represent a specific level of access or a particular set of resources. When your application initiates an authorization request, it includes a space-separated list of scopes in the scope parameter. ClassLink then interprets these scopes and, based on user consent, determines what data your application is allowed to retrieve once it obtains an access_token.

Without scopes, an application might either get blanket access to all user data (a major security risk) or no access at all. Scopes provide the necessary granularity, allowing users to understand and control what parts of their information they are sharing.

Common ClassLink Scopes

ClassLink, being an OpenID Connect provider and a robust educational platform, defines a variety of scopes. These scopes typically fall into two categories: 1. OpenID Connect Standard Scopes: These are standard OIDC scopes for identity verification and basic profile information. 2. ClassLink-Specific Scopes: These grant access to specific ClassLink resources, primarily through the Roster Server apis or other ClassLink api services.

Here's a table summarizing some common and important ClassLink-related scopes:

Scope Name	Description	Standard/ClassLink Specific	Example Data Accessed	Importance
openid	Required for OpenID Connect. Indicates that the client wants to use OpenID Connect for user authentication and receive an id_token.	Standard	User's unique identifier (sub), claims about the authentication event.	Essential for verifying user identity.
profile	Grants access to the user's default profile claims (e.g., name, given_name, family_name, middle_name, nickname, preferred_username, profile, picture, website, gender, birthdate, zoneinfo, locale, updated_at).	Standard	Basic user profile information.	Common for personalized application experiences.
email	Grants access to the user's email address and email_verified status.	Standard	User's primary email address.	Frequently used for communication or account identification.
roster.users.basic	Grants basic read access to user data from ClassLink Roster Server. Typically includes basic user identifiers, names, and roles.	ClassLink Specific	userId, username, firstName, lastName, role.	Fundamental for many EdTech applications needing basic user context.
roster.schools.basic	Grants basic read access to school data from ClassLink Roster Server.	ClassLink Specific	schoolId, schoolName.	For applications needing to display or filter data by school.
roster.orgs.basic	Grants basic read access to organization (district) data from ClassLink Roster Server.	ClassLink Specific	orgId, orgName.	For applications operating at the district level.
roster.classes.basic	Grants basic read access to class data from ClassLink Roster Server.	ClassLink Specific	classId, className, courseTitle.	For LMS, grading, or other classroom management tools.
roster.enrollments.basic	Grants basic read access to enrollment data (who is in what class) from ClassLink Roster Server.	ClassLink Specific	User-class relationships.	Essential for applications needing to understand student/teacher class assignments.
roster.grades.read	Grants read access to grade data from ClassLink Roster Server (if available and configured).	ClassLink Specific	Specific grade information.	For gradebook integrations or student progress tracking.
api.gateway.access	This is not a standard ClassLink scope but a conceptual representation. If ClassLink were to offer a specific scope for broader API access through a generalized gateway (like a ClassLink-managed api gateway for its ecosystem partners), this might be its form.	Conceptual/Internal	Broader permissions for api interactions, potentially managed by an api gateway.	Important for strategic api platform management.

Note: The exact list and behavior of ClassLink-specific scopes can evolve. Always refer to the official ClassLink developer documentation for the most current and accurate information.

Requesting Appropriate Scopes – Principle of Least Privilege

The fundamental rule when requesting scopes is the principle of least privilege. Your application should only request the minimum set of permissions (scopes) it absolutely needs to function correctly. Requesting overly broad scopes, even if technically possible, is a significant security and privacy risk for several reasons: * Increased Attack Surface: More permissions mean more data potentially exposed if your application is compromised. * User Distrust: Users are less likely to grant consent to applications that ask for excessive or irrelevant permissions. This can lead to lower adoption rates. * Compliance Risks: Over-collecting data can complicate compliance with data privacy regulations (e.g., FERPA, GDPR, CCPA).

For example, if your application only needs to display the user's name and email, then openid profile email might be sufficient. There's no need to request roster.classes.basic unless your application genuinely interacts with class data.

User Consent and Its Implications

When an application requests scopes, ClassLink is responsible for presenting these requests to the user in an understandable manner. The user then explicitly grants or denies consent. * Granting Consent: If the user grants consent, ClassLink will proceed with the authorization flow, ultimately issuing an access_token that is scoped to the permissions the user approved. * Denying Consent: If the user denies consent, ClassLink will redirect back to the redirect_uri with an error=access_denied parameter. Your application must gracefully handle this scenario, perhaps by informing the user that access was denied and explaining why the requested permissions are necessary.

It's important to note that user consent is often "sticky." Once a user grants consent for a particular set of scopes to an application, ClassLink typically remembers this. Subsequent authorization requests from the same application for the same scopes may not prompt the user for consent again, leading to a smoother experience. However, if your application requests new or additional scopes later, ClassLink will prompt the user for consent specifically for those new permissions. This is why careful planning of your required scopes from the outset is crucial.

By thoughtfully selecting and managing scopes, developers can build applications that are not only functional but also secure, privacy-respecting, and instill confidence in educational users and institutions alike.

Best Practices for Integrating with ClassLink Authorization Endpoint

Integrating with the ClassLink Authorization Endpoint is more than just knowing which parameters to send; it's about adhering to a set of best practices that ensure security, reliability, and a positive user experience. These practices are derived from industry standards for OAuth 2.0 and OpenID Connect and are specifically tailored to the nuances of EdTech environments.

Secure Client Application Design

The security of your integration begins with the design of your client application. * Protecting Client Secrets: If your application is a "confidential client" (i.e., it can securely store a client_secret on a server), ensure that this secret is never exposed in client-side code, public repositories, or logs. Use environment variables, secure configuration management systems, or dedicated secret management services. Rotate your client_secret periodically as a standard security hygiene practice. * Implementing PKCE (Proof Key for Code Exchange): For "public clients" (e.g., single-page applications, mobile applications) where a client_secret cannot be kept confidential, PKCE is an absolute necessity. PKCE effectively adds a client-specific secret to the authorization code flow, mitigating the risk of authorization code interception. Always use S256 as the code_challenge_method. * Server-Side Token Exchange: The authorization code exchange for access/ID tokens (api calls to the Token Endpoint) must happen server-side. Never perform this exchange directly from client-side JavaScript in a browser. This ensures the client_secret (if used) remains hidden and protects against various token interception attacks. * Validate All Tokens: When your application receives an id_token, rigorously validate it. This involves: * Verifying the JWT signature using ClassLink's public keys (usually available from its OpenID Connect Discovery Endpoint, often /.well-known/openid-configuration). * Checking the aud (audience) claim matches your client_id. * Checking the iss (issuer) claim matches ClassLink's expected issuer URL. * Verifying the exp (expiration) and nbf (not before) claims. * Comparing the nonce claim (if sent) to the nonce value stored in the user's session. * Ensuring the sub (subject) claim is unique and consistent for the user. * Secure Storage of Tokens: Access tokens should be stored securely and only for their necessary lifespan. Never store refresh_tokens in client-side storage like local storage or cookies without the HttpOnly flag. For web applications, secure HttpOnly cookies are often preferred for refresh_tokens. Access tokens for API calls can be kept in memory or session storage.

Managing Redirect URIs

The redirect_uri is a crucial security parameter. * Strict Whitelisting: Ensure that all redirect_uris your application uses are explicitly registered and whitelisted in your ClassLink application configuration. Any redirect_uri not on the whitelist will result in an invalid_redirect_uri error. * Specificity: Be as specific as possible with your redirect_uris. Avoid using wildcard URLs (e.g., https://your-app.com/*) if possible, as this can open up vulnerabilities. Each redirect_uri should point to a specific, hardened endpoint in your application. * HTTPS Only: Always use HTTPS for your redirect_uris. ClassLink will typically enforce this, as unencrypted redirect URIs can expose authorization codes and state parameters to interception.

Handling State Parameter

The state parameter is your first line of defense against Cross-Site Request Forgery (CSRF). * Generate Randomly: Generate a cryptographically secure, unpredictable random string for each authorization request. * Store in Session: Store this state value in the user's session (or other secure, client-specific storage that persists across the redirect). * Validate on Callback: When ClassLink redirects back to your redirect_uri, retrieve the state parameter from the URL and compare it with the stored value. If they do not match, immediately reject the request and terminate the flow. This indicates a potential CSRF attack. * Single-Use: Once the state has been validated, it should be immediately invalidated (e.g., removed from the session) to prevent replay attacks.

User Experience

While security is paramount, a poor user experience can hinder adoption. * Clear Consent Prompts: If ClassLink presents a consent screen, ensure your users understand why your application needs certain permissions. While ClassLink controls the prompt, your application's design should align with the requested scopes. * Graceful Error Handling: As discussed, prepare for various error responses. Don't show raw technical error codes to the user. Instead, present user-friendly messages that explain the issue and suggest actionable steps (e.g., "Login failed: You denied access. Please try again and grant permissions if you wish to use this app."). * Loading Indicators: During the redirect dance, provide visual feedback (e.g., a loading spinner) to assure the user that the process is ongoing and the page hasn't simply frozen.

Testing Strategies

Thorough testing is non-negotiable for robust integrations. * Unit Tests: Test individual components of your OAuth/OIDC implementation (e.g., state generation and validation, token parsing and validation). * Integration Tests: Simulate the full authorization code flow, from initiating the redirect to exchanging the code for tokens and making an api call. Test success paths and various error paths. * End-to-End Tests: Verify the complete user journey, including login via ClassLink, consent, and accessing features in your application that rely on ClassLink data. * Security Scans and Penetration Testing: Regularly subject your application to security audits, especially focusing on authentication and authorization flows, to identify vulnerabilities.

Monitoring and Logging

Once in production, continuous monitoring and detailed logging are essential for maintaining a healthy integration. * Log Authorization Attempts: Record details of authorization requests (without sensitive data like client_secret or raw codes) and their outcomes (success, various error types). * Monitor Token Lifecycles: Track token issuance, refresh attempts, and expiry. * Alerting: Set up alerts for unusual activity, frequent authentication failures, or error patterns that could indicate an attack or an issue with your integration.

The Role of an API Gateway in Integration Management

As integrations with platforms like ClassLink become more complex, encompassing multiple applications, diverse apis, and stringent security requirements, the value of an api gateway becomes incredibly apparent. An api gateway acts as a single entry point for all api calls, abstracting away the complexities of backend services and providing a centralized point for managing traffic, security, and policies.

This is precisely where a solution like APIPark shines. APIPark, as an open-source AI gateway and api management platform, can play a pivotal role in mastering your ClassLink integrations and overall api ecosystem. For instance, instead of each of your applications directly implementing the OAuth 2.0/OIDC flow with ClassLink, you could configure APIPark to handle this on their behalf. APIPark could:

• Standardize Authentication: Unify authentication mechanisms across various apis, including those from ClassLink. It can handle the intricacies of openid and OAuth 2.0 flows, allowing your downstream applications to interact with a simpler, standardized api interface exposed by the gateway.
• Centralized Security Policies: Enforce security policies like rate limiting, api key validation, and JWT validation for access tokens obtained from ClassLink. APIPark can validate the id_token and access_token issued by ClassLink before forwarding requests to your backend services, adding an extra layer of security.
• Traffic Management: Provide robust traffic management capabilities, load balancing, and routing for api requests to ClassLink or your own services that consume ClassLink data.
• Unified API Access: If you have multiple internal apis that rely on ClassLink data, APIPark can serve as the gateway that manages their access to ClassLink, ensuring consistent security and performance.
• Detailed Logging and Analytics: Offer comprehensive logging of all api calls, including those related to ClassLink interactions, providing invaluable data for monitoring, auditing, and troubleshooting. This centralized visibility is crucial for understanding the health and security of your integrations.

By leveraging an api gateway like APIPark, organizations can streamline the management of their ClassLink integrations, enhance security posture, improve performance, and reduce the operational overhead associated with managing numerous api clients and their authorization flows. It transforms a collection of individual api connections into a cohesive, well-governed api ecosystem. This is particularly beneficial in EdTech, where managing secure access to sensitive data across many applications is a constant challenge.

Advanced Topics and Troubleshooting

While mastering the basic Authorization Code Grant flow is essential, understanding advanced topics and common troubleshooting scenarios will elevate your ClassLink integration capabilities, enabling you to build more resilient, scalable, and user-friendly applications.

Session Management

User sessions play a crucial role in the overall authentication experience. * ClassLink Session: When a user successfully logs into ClassLink (via the Authorization Endpoint), ClassLink establishes its own user session. This means that if the user attempts to access another application integrated with ClassLink, they may not be prompted to re-enter their credentials, leading to a true single sign-on experience. This behavior is often controlled by the prompt parameter (e.g., prompt=none attempts silent re-authentication using the existing ClassLink session). * Client Application Session: Your application must also manage its own session for the user. After successfully obtaining and validating the id_token, your application typically creates a local user session (e.g., by setting a secure, HttpOnly session cookie). The duration of this session should be carefully considered; it should ideally be shorter than the refresh_token lifetime (if refresh tokens are used) or the user's expected activity period, requiring re-authentication when expired. * Logout and Session Termination: Proper logout mechanisms are vital. When a user logs out of your application, you should: 1. Invalidate your application's session. 2. If desired, redirect the user to ClassLink's End Session Endpoint (logout endpoint) to terminate their ClassLink session as well. This ensures a complete logout across all connected applications. The ClassLink logout endpoint typically accepts parameters like id_token_hint and post_logout_redirect_uri.

Refresh Tokens

Refresh tokens are long-lived credentials (issued at the Token Endpoint, not the Authorization Endpoint) that allow a client application to obtain new access_tokens without requiring the user to re-authenticate. * Usage: When an access_token expires, your application uses the refresh_token in a special request to ClassLink's Token Endpoint (with grant_type=refresh_token) to get a new access_token. This significantly improves user experience by minimizing re-logins. * Security: Refresh tokens are highly sensitive and must be treated with extreme care. They should only be stored on secure servers (for confidential clients) and never exposed client-side. If a refresh_token is compromised, an attacker could potentially obtain new access_tokens indefinitely. * Revocation: ClassLink, as the authorization server, must provide a mechanism for revoking refresh_tokens (e.g., if a user explicitly logs out or a compromise is suspected).

Multi-Tenancy and Multiple ClassLink Instances

Educational districts often operate as distinct tenants within the ClassLink ecosystem. Your application might need to support integration with multiple, independent ClassLink instances or different configurations for various districts. * Dynamic Configuration: Your application should be designed to dynamically configure the ClassLink Authorization Endpoint URL, client_id, client_secret, and redirect_uri based on the district or tenant the user belongs to. This often involves a "discovery" phase where the user identifies their district, and your application then retrieves the correct ClassLink configuration for that district. * Metadata Endpoints: OpenID Connect providers like ClassLink often publish a "Discovery Document" at a well-known URL (e.g., https://launchpad.classlink.com/oauth2/v2/.well-known/openid-configuration). This document contains all the necessary endpoint URLs, supported scopes, public keys (for JWT validation), and other configuration details. Your application should leverage this dynamically to avoid hardcoding.

Common Integration Pitfalls and Their Solutions

1. Mismatched redirect_uri:
   • Pitfall: The redirect_uri sent in the authorization request does not exactly match a pre-registered URI in ClassLink. Even a trailing slash or capitalization difference can cause failure.
   • Solution: Double-check your ClassLink application configuration and your code to ensure an exact match. Use encodeURIComponent for the redirect_uri in the request.
2. Invalid scope:
   • Pitfall: Requesting a scope that ClassLink does not support or that your application is not authorized for.
   • Solution: Consult ClassLink's official documentation for supported scopes. Only request necessary scopes.
3. Missing or Invalid state Parameter:
   • Pitfall: Failing to send a state parameter or not validating it on callback.
   • Solution: Always generate a unique state for each request, store it securely, and rigorously validate it upon redirect.
4. Client Secret Exposure:
   • Pitfall: Hardcoding client_secret in client-side JavaScript or checking it into public source control.
   • Solution: Keep client_secret strictly server-side. Use environment variables or secret management. Implement PKCE for public clients.
5. Expired Authorization Code:
   • Pitfall: Taking too long to exchange the authorization code for tokens (authorization codes have a very short lifespan, typically 1-10 minutes).
   • Solution: Implement the token exchange immediately after receiving the authorization code.
6. JWT Validation Failures:
   • Pitfall: Incorrectly validating the id_token (e.g., not verifying signature, aud, iss, exp, nonce).
   • Solution: Use robust, well-tested OIDC client libraries. Ensure you are fetching ClassLink's public keys from the correct JWKS endpoint (jwks_uri in the discovery document) to verify signatures.

Performance Considerations for High-Volume Environments

For large districts or widespread applications, performance and scalability are key. * Efficient Token Handling: Minimize the number of token exchange calls. Reuse access_tokens until they expire. Leverage refresh_tokens efficiently. * Caching: Cache ClassLink's public keys (from the jwks_uri) to avoid fetching them on every id_token validation. Implement appropriate cache invalidation strategies. * API Gateway for Scale: For applications managing hundreds or thousands of concurrent users, an api gateway like APIPark becomes an invaluable asset. It can: * Handle Concurrent Requests: A robust gateway can manage a high volume of concurrent api requests, directing traffic efficiently to ClassLink's Authorization and Token Endpoints, or to your backend services that rely on ClassLink data. APIPark, for example, is noted for its performance, capable of achieving over 20,000 TPS with modest resources, and supporting cluster deployment for even larger scale. This ensures that the gateway itself doesn't become a bottleneck during peak usage. * Offload Security Tasks: The gateway can perform security tasks such as token validation, rate limiting, and request logging, reducing the load on your backend application servers. * Centralized Policies: Apply policies uniformly across all api integrations, ensuring consistent behavior and security even as your application portfolio grows. * Monitoring and Analytics: Provide a centralized dashboard for all api traffic, offering deep insights into performance, errors, and usage patterns, which is critical for proactive maintenance and issue resolution in high-volume settings.

By proactively addressing these advanced topics and potential pitfalls, and by strategically employing technologies like a high-performance api gateway, developers can build ClassLink integrations that are not only functional but also secure, scalable, and maintainable in the long term, serving the dynamic needs of the educational sector.

Future Trends and Evolution of Authorization

The digital landscape is in a constant state of flux, and the realm of authorization and identity management is no exception. While OAuth 2.0 and OpenID Connect form the bedrock of current practices, emerging trends and technologies are set to further reshape how applications securely interact with platforms like ClassLink and manage user access. Staying abreast of these developments is crucial for building future-proof EdTech solutions.

FIDO Alliance, Passkeys, and Decentralized Identity

• FIDO Alliance and Passkeys: The FIDO (Fast Identity Online) Alliance promotes open standards for simpler, stronger authentication. "Passkeys," built on FIDO standards, represent a significant leap beyond traditional passwords. They use cryptographic key pairs unique to each website or application, stored securely on a user's device (like a smartphone or computer). When a user logs in, their device verifies their identity (e.g., via fingerprint, facial recognition, or PIN) and sends a cryptographic signature to the service. This eliminates phishing, credential stuffing, and other password-related attacks. As FIDO and passkeys gain wider adoption, we can anticipate ClassLink, like other major identity providers, incorporating support for them, fundamentally changing how users authenticate at the Authorization Endpoint.
• Decentralized Identity (DID): Decentralized Identity, often built on blockchain or distributed ledger technology, aims to give individuals more control over their digital identities. Instead of relying on central authorities (like ClassLink or Google) to issue and verify identity credentials, users would hold "verifiable credentials" in their digital wallets. They could then selectively present these credentials to services, without revealing unnecessary personal information. While still nascent for widespread enterprise adoption, DID has profound implications for privacy and user agency in EdTech, potentially allowing students and teachers to manage and share their educational records with greater control. The Authorization Endpoint might evolve to handle requests for verifiable credentials rather than simply relying on centrally managed identity proofs.

Continuous Authorization and Fine-Grained Access Control

Traditional authorization often involves a one-time grant of permissions at the start of a session. However, the concept of "continuous authorization" is gaining traction. * Dynamic Risk Assessment: This involves constantly assessing the risk level of an ongoing user session based on various factors (e.g., location changes, device posture, unusual activity patterns). If the risk level escalates, authorization decisions can be dynamically re-evaluated, potentially leading to additional authentication challenges (step-up authentication) or even automatic revocation of access. * Attribute-Based Access Control (ABAC): Moving beyond role-based access control, ABAC grants permissions based on a combination of attributes of the user, resource, action, and environment. For EdTech, this could mean highly granular permissions like "a teacher can access the grades of students in their assigned classes, but only between 8 AM and 4 PM on weekdays." Implementing such fine-grained controls would necessitate a more sophisticated authorization policy engine, potentially influencing the parameters sent to and returned from the Authorization Endpoint, or requiring more advanced api gateway capabilities for runtime policy enforcement.

Impact on EdTech

These trends hold significant promise for the educational sector: * Enhanced Security: Passkeys and FIDO standards can drastically reduce the risk of credential theft, a major concern with student data. * Improved Privacy: Decentralized identity and fine-grained access control empower students and educators with greater control over their personal and educational data, aligning with evolving privacy regulations like FERPA and GDPR. * Streamlined User Experience: While seemingly complex, these advancements are designed to simplify the user experience over time, making secure access more intuitive and less burdensome.

For developers and organizations integrating with ClassLink, this means a continuous learning curve and an imperative to design systems that are adaptable and extensible. The underlying apis and the gateway services that manage them will need to evolve to support these new paradigms. The Authorization Endpoint, while remaining a critical entry point, may become part of an even more intelligent and adaptive authorization ecosystem, moving towards a world where secure, user-centric access is not just a feature, but a seamless and invisible foundation of all digital interactions. Organizations utilizing robust api management platforms and api gateway solutions, such as APIPark, will be better positioned to adapt to these changes, as these platforms are inherently designed to abstract complexity and provide flexible policy enforcement and integration capabilities.

Conclusion

Mastering the ClassLink Authorization Endpoint is not merely a technical exercise; it is an essential competency for any developer or organization committed to building secure, efficient, and user-centric applications within the educational technology landscape. This journey has taken us from the foundational principles of OAuth 2.0 and OpenID Connect to the meticulous dissection of ClassLink's specific implementation, culminating in a discussion of best practices, advanced topics, and future trends.

We have emphasized the critical importance of understanding each parameter in the authorization request – from the ubiquitous client_id and redirect_uri to the security-critical state and PKCE (code_challenge) parameters. The multi-step Authorization Code Grant flow, with its backend token exchange, stands as the most robust method for securing sensitive data in EdTech, preventing credential exposure and mitigating common attack vectors. Furthermore, a deep dive into ClassLink's scopes has highlighted the necessity of adhering to the principle of least privilege, ensuring that applications only ever access the data they absolutely require, thereby safeguarding student and educator privacy.

Beyond the mechanics, this guide has underscored the paramount importance of secure client application design, rigorous redirect_uri management, meticulous state parameter handling, and comprehensive testing strategies. For organizations dealing with growing api complexity and scaling integration efforts, the strategic adoption of an api gateway or api management platform like APIPark emerges not just as a recommendation, but as a transformative solution. APIPark's capabilities in standardizing api access, centralizing security policies, managing traffic, and providing detailed analytics offer a robust framework to streamline ClassLink integrations, enhance their security posture, and ensure their long-term performance and maintainability. By serving as a unified gateway for all api interactions, it simplifies the intricacies of multiple integrations, allowing developers to focus on core application logic rather than repetitive authorization plumbing.

Looking ahead, the evolution of authorization, with innovations like FIDO-based passkeys, decentralized identity, and continuous authorization, promises an even more secure and user-empowered future for EdTech. Adapting to these changes will require flexible and robust api infrastructure, making the investment in comprehensive api management all the more critical.

In essence, mastering the ClassLink Authorization Endpoint means embracing a holistic approach to secure api integration. It means understanding the protocols, implementing best practices, anticipating pitfalls, and strategically leveraging powerful tools. By doing so, developers can confidently build applications that not only deliver exceptional educational experiences but also uphold the highest standards of data privacy and security, fostering trust in the digital tools that shape the future of learning.

---

Frequently Asked Questions (FAQs)

1. What is the primary purpose of the ClassLink Authorization Endpoint? The ClassLink Authorization Endpoint serves as the initial gateway for an application to initiate the process of user authentication and obtaining consent to access specific user data. It redirects the user to ClassLink's login page, handles their authentication, and if consent is granted, redirects them back to the application with a temporary authorization code. This code is then exchanged for actual access and ID tokens.

2. Why is the state parameter crucial when interacting with the ClassLink Authorization Endpoint? The state parameter is a critical security measure used to prevent Cross-Site Request Forgery (CSRF) attacks. Your application generates a unique, unpredictable state value for each authorization request, stores it securely (e.g., in a session), and expects to receive the exact same value back from ClassLink. If the received state does not match the stored state, it indicates a potential attack, and the request should be rejected.

3. What is PKCE, and why is it recommended for ClassLink integrations? PKCE (Proof Key for Code Exchange) is an extension to the Authorization Code Grant flow designed to protect public clients (like single-page applications or mobile apps) from authorization code interception attacks. It involves the client generating a code_verifier and sending a code_challenge (a hash of the verifier) to the Authorization Endpoint. When exchanging the authorization code for tokens, the client sends the original code_verifier to the Token Endpoint. ClassLink then verifies that the code_verifier matches the code_challenge it initially received. PKCE is highly recommended as it adds a layer of security without requiring a client_secret to be stored securely on the client.

4. What are "scopes," and how should I choose them for my ClassLink application? Scopes are predefined permissions that define the specific user data or resources your application is requesting access to from ClassLink. Examples include openid (for identity verification), profile (for basic user profile information), or roster.users.basic (for basic roster user data). You should always adhere to the "principle of least privilege" when choosing scopes, meaning you should only request the absolute minimum set of permissions necessary for your application to function. Requesting too many scopes can raise privacy concerns for users and increase your application's attack surface.

5. How can an api gateway like APIPark enhance ClassLink integrations? An api gateway like APIPark can significantly enhance ClassLink integrations by providing a centralized platform for api management. It can abstract away the complexities of OAuth 2.0/OIDC flows, enforce security policies (like token validation, rate limiting, and access control) at the gateway level, manage traffic and load balancing, and provide comprehensive logging and analytics for all api calls. This not only streamlines the development and deployment of applications integrating with ClassLink but also improves overall security, performance, and maintainability of the entire api ecosystem.

🚀You can securely and efficiently call the OpenAI API on APIPark in just two steps:

Step 1: Deploy the APIPark AI gateway in 5 minutes.

APIPark is developed based on Golang, offering strong product performance and low development and maintenance costs. You can deploy APIPark with a single command line.

curl -sSO https://download.apipark.com/install/quick-start.sh; bash quick-start.sh

In my experience, you can see the successful deployment interface within 5 to 10 minutes. Then, you can log in to APIPark using your account.

Step 2: Call the OpenAI API.