What is OAuth?

OAuth (Open Authorization) is an industry-standard authorization framework that enables third-party applications to obtain limited access to an API service on behalf of a user, without the user sharing their credentials with the third-party application. OAuth 2.0, the current version, defines several authorization flows (called "grant types") designed for different application architectures, including web applications, mobile apps, server-to-server communication, and single-page applications.

The OAuth 2.0 framework involves four roles: the resource owner (typically the end user), the client (the third-party application requesting access), the authorization server (which authenticates the user and issues tokens), and the resource server (the API that hosts the protected data). The core principle is that the user authenticates directly with the authorization server, which then issues an access token to the client. The client uses this token to access the resource server, never handling the user's actual credentials.

The most commonly used grant types include the Authorization Code flow for server-side web applications, the Authorization Code with PKCE (Proof Key for Code Exchange) flow for mobile and single-page applications, the Client Credentials flow for server-to-server communication where no user context is needed, and the Refresh Token flow for obtaining new access tokens without re-authentication.

Access tokens are typically short-lived (minutes to hours) to limit the window of exposure if a token is compromised. Refresh tokens have a longer lifetime and can be used to obtain new access tokens without requiring the user to re-authenticate. Scopes define the specific permissions granted to a token, allowing fine-grained control over what the client can access.

Why It Matters

OAuth solves a fundamental security problem in API integrations: how to grant third-party access to a service without sharing the user's password. Before OAuth, integrations often required users to provide their credentials directly to third-party applications, creating significant security risks. If the third-party application was compromised, the user's credentials were exposed. There was no way to limit the scope of access or revoke access without changing the password.

OAuth eliminates these risks by separating authentication from authorization. The user's credentials are handled only by the authorization server, never by the third-party application. Access is controlled through tokens with defined scopes and lifetimes, and access can be revoked by invalidating the token without affecting the user's password. This model provides both security and flexibility.

In the trademark data context, OAuth is particularly important for applications that access trademark data on behalf of individual users. A trademark management platform that integrates with Signa's API needs to access each user's monitored marks, saved searches, and alert preferences. OAuth ensures that each user's data is accessed only with their explicit authorization and only within the scope they have granted.

OAuth also enables platform ecosystems. When a trademark data provider supports OAuth, it allows a marketplace of third-party applications to build on top of the platform. Legal tech tools, analytics dashboards, portfolio management systems, and brand protection services can all access the platform's data with user consent, creating a richer ecosystem of tools and services.

How Signa Helps

Signa supports the full OAuth 2.0 specification, enabling secure and flexible integration patterns for every application architecture. The platform operates both the authorization server and the resource server, providing a unified authentication experience.

For web applications that access Signa on behalf of individual users, the platform supports the Authorization Code flow with PKCE. The client application redirects the user to Signa's authorization endpoint, where they authenticate and approve the requested scopes. Upon approval, Signa redirects back to the client with an authorization code, which the client exchanges for an access token and refresh token. This flow keeps user credentials secure and provides tokens with explicitly defined permissions.

For server-to-server integrations where no user context is needed, Signa supports the Client Credentials flow. The client authenticates directly with Signa's token endpoint using its client ID and client secret, receiving an access token that grants access based on the client's own permissions rather than any individual user's permissions.

Signa's OAuth implementation defines granular scopes that allow clients to request only the permissions they need. Available scopes include trademarks:read for search and retrieval, trademarks:analyze for clearance and analysis operations, monitors:read and monitors:write for monitoring configuration, and webhooks:manage for webhook management. This fine-grained scope model follows the principle of least privilege, ensuring that each client has only the access it requires.

Access tokens issued by Signa are signed JWTs that can be verified locally by the client without making a network call to Signa's servers. This design enables low-latency token validation in performance-critical applications. Tokens include standard JWT claims such as issuer, audience, expiration, and scope, as well as custom claims for account-specific information.

The platform's token management dashboard allows account administrators to view active OAuth clients, review granted scopes, and revoke access at any time. Audit logs record all OAuth events, including token issuance, refresh, and revocation, providing full visibility into access patterns.

Real-World Example

A legal technology company builds a trademark clearance tool that allows attorneys to search Signa's database from within their existing workflow management software. The tool needs to access Signa on behalf of each individual attorney, ensuring that search results, saved queries, and monitoring preferences are personalized.

The company registers as an OAuth client with Signa, receiving a client ID and client secret. When an attorney first uses the trademark clearance feature, the tool redirects them to Signa's authorization page, where they sign in and approve the requested scopes: trademarks:read and trademarks:analyze. The tool receives an access token and a refresh token.

Subsequent API calls include the access token in the Authorization header. When the access token expires after one hour, the tool automatically uses the refresh token to obtain a new access token without interrupting the attorney's workflow. The attorney's credentials are never exposed to the legal tech company's servers.

If the law firm terminates its relationship with the legal tech company, its administrators can revoke all OAuth grants through Signa's dashboard, immediately cutting off the company's access to the firm's data. This revocation is immediate and does not require changing any passwords or API keys, demonstrating the clean separation of concerns that OAuth provides.