# Third-party authorisation

> Source: Courseiva IT Certification Glossary — https://courseiva.com/glossary/third-party-authorisation

## Quick definition

Third-party authorisation means using an outside service to check if you are allowed to access something. Instead of the app or website making that decision on its own, it asks a trusted company, like Google or Microsoft, to confirm who you are and what you can do. This approach helps reduce security risks and simplifies system design.

## Simple meaning

Imagine you want to enter a private club. Instead of the club staff checking your ID themselves, they have a trusted friend of yours vouch for you. That friend checks your ID, confirms you are who you say you are, and tells the club you are allowed in. In the digital world, third-party authorisation works similarly. A website or application does not manage your login or permissions directly. Instead, it relies on an external service, like a social media platform or a corporate identity provider, to verify your identity and confirm what you are allowed to do.

This is different from a system that stores usernames and passwords locally. When a system uses third-party authorisation, it sends you to the external service to log in. That service then sends a secure token back to the original system, which contains information about your identity and permissions. The original system trusts this token because it comes from a known, reliable source.

Think of it like using a hotel key card. The hotel does not need to know your personal details; it only trusts the card that was issued by the hotel's security system. If the card says you are allowed on the tenth floor, the elevator believes it. Third-party authorisation follows this same trust model, but it uses cryptographic signatures and secure protocols instead of physical cards. This separation of duties helps keep your data safer because your login credentials are not stored in multiple places, and you only need to manage one set of passwords for many services.

## Technical definition

Third-party authorisation is a security model in which the decision to grant or deny access to a resource is delegated to an external identity provider (IdP) or authorisation server. This model is a core component of modern identity and access management (IAM) frameworks, including OAuth 2.0, OpenID Connect, and SAML 2.0. These protocols allow a resource server (the application or API) to trust assertions made by a separate authorisation server, such as Azure Active Directory, Okta, or Auth0.

The process works through the issuance of access tokens, which are typically JSON Web Tokens (JWTs) or SAML assertions. A client application first requests authorisation from the resource owner (the user). The client then redirects the user to the authorisation server, where the user authenticates and consents to specific scopes. The authorisation server then issues an authorisation code (in the OAuth 2.0 flow) or an ID token (in OpenID Connect), which the client exchanges for an access token. This access token contains claims about the user's identity and permissions, signed by the authorisation server using asymmetric cryptography (e.g., RSA or ECDSA).

In enterprise environments, third-party authorisation is often implemented using SAML for single sign-on (SSO). Here, the IdP issues a digitally signed assertion that includes the user's identity and attributes. The service provider (e.g., Salesforce or a custom web app) verifies the signature against a pre-shared certificate. If valid, the user is granted access based on the attributes in the assertion, such as group memberships or roles.

From a security perspective, third-party authorisation reduces the attack surface by centralising credential management and enforcing policy at a single point. It also enables fine-grained access control through scopes and claims. However, it introduces dependencies on the external IdP's availability and security posture. If the IdP is compromised, all trusting applications are potentially at risk. Best practices include implementing token expiry, rotating signing keys, and using audience restrictions to limit which clients can accept tokens.

## Real-life example

Consider a modern office building with multiple floors, each restricted to different employee groups. Instead of giving every employee a physical key for every floor, the building has a central security desk. When an employee wants to enter a restricted floor, they scan their badge at the elevator. The elevator does not check the badge itself; it sends a request to the central security system. That system has a database of who is allowed on each floor. It checks the employee's badge number against the access list for that floor and sends a signal back to the elevator to either open or stay locked.

This is exactly how third-party authorisation works. The elevator is like the resource server-it does not store access permissions. The central security system is the third-party authorisation server. The badge is the access token. The employee never shows a list of floors they can enter; the elevator trusts the security system's response.

In the digital world, a similar scenario occurs when you use a Google account to log into a third-party app like Trello. Trello does not store your password. Instead, it redirects you to Google's login page. Once you authenticate, Google gives Trello a token that says, 'This user is allowed to create boards and cards.' Trello trusts that token because it is signed by Google. Just as the elevator trusts the security system, Trello trusts Google's authorisation decision.

## Why it matters

In practical IT environments, third-party authorisation is critical for scalability and security. Managing user credentials and permissions locally within every application leads to administrative overhead and increased security risk. If any one application is compromised, that application's stored passwords become exposed. By centralising authorisation with a trusted third party, organisations reduce the number of places where sensitive credential information is stored.

third-party authorisation enables seamless user experiences through single sign-on (SSO). Users can authenticate once and access multiple applications without re-entering passwords. This reduces password fatigue and helps enforce stronger password policies because users only need to remember one set of credentials. For IT administrators, it simplifies user lifecycle management-when an employee leaves the company, disabling their account at the IdP immediately revokes access to all integrated applications.

Third-party authorisation also supports fine-grained access control through claims-based authorisation. Administrators can define roles and permissions in one central location and enforce them across many applications. For example, an HR application can receive a claim indicating that a user is a 'Manager,' and the application can authorise special features based on that claim. This pattern is deeply embedded in cloud-native architectures and microservices, where many different services need to trust a common identity source.

## Why it matters in exams

Third-party authorisation appears in many IT certification exams, including CompTIA Security+, CISSP, and AWS Certified Solutions Architect. In CompTIA Security+, it is covered under domain 3 (Implementation) and domain 4 (Operations and Incident Response). You will see questions about federated identity, SAML, and OAuth. In CISSP, it is part of Domain 5 (Identity and Access Management) and is tested through scenario-based questions that ask you to choose the appropriate access control model for a given organisational need.

In AWS exams, third-party authorisation is heavily tested in the context of IAM roles, Cognito, and integrating with external IdPs. You may be asked to design a solution where users authenticate via a corporate IdP and assume an IAM role to access AWS resources. Understanding token-based authorisation flows is essential for these questions.

For the Security+ exam, expect multiple-choice questions that ask you to distinguish between authentication and authorisation or to identify the protocol used for third-party authorisation (e.g., Which of the following is used for web-based SSO?). You might also see a scenario where an organisation wants to reduce the risk of credential theft by not storing passwords locally-here you need to recommend using a third-party authorisation service.

In the CISSP exam, questions are more conceptual. You may be asked to evaluate the security implications of delegating authorisation to a third party. For example, 'Which risk is introduced when using a federated identity model?' The correct answer often involves the risk of a single point of failure or the need to trust the external IdP's security controls. Being able to discuss the trade-offs-like reduced credential exposure versus increased dependency-is key.

## How it appears in exam questions

Exam questions on third-party authorisation typically fall into three categories: scenario-based, protocol identification, and troubleshooting.

Scenario-based questions present a situation where an organisation is implementing SSO across multiple applications. You might be asked: 'A company wants employees to log in once using their corporate credentials and access both the internal HR system and a third-party cloud CRM. Which approach should they use?' The correct answer would be to implement SAML-based federation with the CRM as the service provider and the corporate Active Directory as the IdP.

Protocol identification questions ask you to match a protocol to its description. For example: 'Which protocol uses tokens signed with asymmetric keys to authorise third-party application access?' The answer is OAuth 2.0 or OpenID Connect, depending on the context. You need to know that OAuth is an authorisation framework, while OpenID Connect adds an identity layer on top.

Troubleshooting questions might give you a log entry or error message. For instance: 'A user is receiving an 'Access denied' error after successfully logging in via a third-party IdP. The token contains the correct claims but the user still cannot access the resource. What is most likely the issue?' The answer could be that the resource server is not configured to accept tokens from that IdP, or the token's audience claim does not match the resource server's identifier.

Another common pattern is comparing third-party authorisation with other models. You might see: 'Which of the following is a disadvantage of using third-party authorisation?' The correct answer often relates to increased reliance on network connectivity or the trustworthiness of the external provider. Having a clear understanding of these patterns will help you answer confidently.

## Example scenario

A medium-sized company, TechCorp, uses multiple cloud-based applications: Salesforce for customer management, Slack for communication, and Jira for project tracking. Employees currently have separate usernames and passwords for each service, which leads to frequent password reset requests and some employees writing down passwords on sticky notes.

The IT department decides to implement third-party authorisation by using their existing Microsoft Azure Active Directory as the central identity provider. They configure Salesforce, Slack, and Jira to trust Azure AD. Now, when an employee tries to log into Salesforce, they are redirected to a Microsoft login page. They enter their corporate credentials, and if the credentials are correct, Azure AD sends a SAML assertion to Salesforce. This assertion includes the employee's identity and their group memberships, such as 'Sales Team' or 'Engineering'.

Salesforce then checks its own rules: if the assertion says the user belongs to the 'Sales Team,' they get read-write access to the CRM module. If the user is from 'Engineering,' they only get read-only access to bug reports. All access revocations happen centrally. When an employee leaves TechCorp, the IT admin disables their Azure AD account, and immediately that employee cannot access Salesforce, Slack, or Jira.

This scenario illustrates the core benefit: centralised control, reduced password fatigue, and consistent authorisation policies across all applications.

## Common mistakes

- **Mistake:** Confusing third-party authorisation with session management.
  - Why it is wrong: Session management handles the user's active session after authentication, whereas third-party authorisation is about delegating the access decision to an external service. They are not the same, though they often work together.
  - Fix: Remember that authorisation is about permissions (what you can do), while session management is about keeping you logged in. Third-party authorisation defines the rules, not the session state.
- **Mistake:** Thinking that OAuth and OpenID Connect are the same.
  - Why it is wrong: OAuth 2.0 is an authorisation framework for delegated access-it issues access tokens. OpenID Connect is an authentication protocol built on top of OAuth 2.0 that also provides an ID token with user identity information. They are related but not interchangeable.
  - Fix: In exams, if the question mentions 'verifying user identity' (authentication), think OpenID Connect. If it is about 'granting access to resources' (authorisation), think OAuth 2.0.
- **Mistake:** Assuming third-party authorisation eliminates the need for local security.
  - Why it is wrong: Even with a third-party IdP, the resource server (application) must validate tokens correctly, enforce its own access rules, and protect against token replay or misuse. Using a third party does not automatically make the system secure.
  - Fix: Treat the third-party token as a credential. Validate its signature, check its expiry, and ensure the audience matches your application. Always apply the principle of least privilege on your side.
- **Mistake:** Believing third-party authorisation always means SSO.
  - Why it is wrong: SSO is a common use case but not the only one. Third-party authorisation can also be used for API access without user interaction (like a server-to-server scenario). SSO implies a user-centric flow, whereas third-party authorisation can be machine-to-machine.
  - Fix: Understand the full scope: third-party authorisation includes any use case where an external authority makes the access decision-user-facing or not.
- **Mistake:** Ignoring the risk of IdP downtime.
  - Why it is wrong: If the third-party IdP is unreachable, all applications that rely on it for authorisation will be unable to grant access to new sessions. This is a single point of failure that must be mitigated with failover or offline token caching.
  - Fix: When designing a system, consider implementing token caching with short timeouts or a backup local authorisation mechanism for critical functions.

## Exam trap

{"trap":"Choosing 'authentication' when the question asks for 'authorisation' in the context of third-party OAuth tokens.","why_learners_choose_it":"Many learners see the term 'token' and automatically think of 'authentication' because tokens are used in both. The question might say 'A third-party service issues a token to allow an app to access a user's data.' This sounds like authentication, but it is actually about authorisation-the token grants permissions, not just identity.","how_to_avoid_it":"Train yourself to read the question carefully. Look for keywords: 'permission,' 'allow,' 'access to resources' point to authorisation. 'Identity,' 'verification,' 'who the user is' point to authentication. In the OAuth context, the access token is for authorisation; the ID token is for authentication."}

## Commonly confused with

- **Third-party authorisation vs Federation:** Federation is a broader concept that establishes trust between entire security domains (such as two organisations). Third-party authorisation is the mechanism that implements that trust-it is the actual process of issuing and validating tokens. Federation sets up the relationship; third-party authorisation executes each access request. (Example: Two companies agreeing to share user identities is federation. Using SAML to log into the partner's app is third-party authorisation.)
- **Third-party authorisation vs Single sign-on (SSO):** SSO is the user experience where a single login gives access to multiple applications. Third-party authorisation is the underlying technical method that enables SSO. Not all SSO implementations use third-party authorisation-some use proprietary or local solutions. But SSO is the outcome, while third-party authorisation is one way to achieve it. (Example: Logging into Google once and automatically being signed into YouTube is SSO. The fact that YouTube trusts Google's authorisation decision is third-party authorisation.)
- **Third-party authorisation vs Role-based access control (RBAC):** RBAC is an access control model that defines permissions based on roles. Third-party authorisation is a mechanism for implementing any access control model, including RBAC. A third-party service can authorise based on roles, attributes, or other claims. RBAC is the 'what,' third-party authorisation is the 'how.' (Example: A system may use RBAC to say 'managers can approve expenses.' Third-party authorisation would be the external service that tells the system what role the current user has.)
- **Third-party authorisation vs Multi-factor authentication (MFA):** MFA is a method of verifying identity by requiring multiple factors (password, phone, biometric). Third-party authorisation is about granting access after identity is confirmed. MFA can happen during the third-party authorisation flow, but they are distinct steps. The IdP might enforce MFA before issuing an authorisation token. (Example: Logging into a corporate portal requires a password and a one-time code from your phone (MFA). If the portal uses a third-party IdP, that IdP is the one performing the MFA check, not the portal itself.)

## Step-by-step breakdown

1. **User requests access to a resource** — The user clicks a link or opens an application that is protected by third-party authorisation. The application (resource server) does not have local login built in-it detects that the user is not authenticated and decides to redirect them to the authorised third-party service.
2. **Application redirects to the third-party IdP** — The application constructs an authorisation request URL and sends the user's browser to the IdP's login page. This request includes parameters such as the client ID (identifying the application), the redirect URI (where the IdP should send the user back), and requested scopes (the permissions the application needs).
3. **User authenticates with the IdP** — The user provides credentials (username, password, MFA code) directly to the IdP. The IdP verifies the identity. Importantly, the application never sees the user's password. The IdP may also present a consent screen asking the user to approve the permissions the application is requesting.
4. **IdP issues an authorisation code or token** — After successful authentication and consent, the IdP generates a short-lived authorisation code (in the OAuth 2.0 code flow) and redirects the user back to the application with that code. The application then exchanges the code for an access token by communicating directly with the IdP's token endpoint.
5. **Application requests a resource with the token** — The application attaches the access token to API calls to the resource server (e.g., a backend API or cloud service). The token is usually sent in the HTTP Authorization header as a Bearer token. The resource server extracts the token.
6. **Resource server validates the token** — The resource server does not trust the token blindly. It validates the token's signature using the IdP's public key, checks the token's expiration time, and verifies that the audience claim matches its own identifier. If any check fails, the request is rejected with a 401 or 403 status code.
7. **Access granted or denied based on claims** — If the token is valid, the resource server examines the claims inside (such as roles, groups, or custom attributes) to determine the user's permissions. It then either serves the requested data or denies access. The entire process ensures that the IdP makes the authorisation decision, not the application itself.

## Practical mini-lesson

When implementing third-party authorisation in a real environment, the first step is selecting an identity provider (IdP). Common choices include Azure Active Directory, Okta, Keycloak, and Auth0. Each IdP supports standard protocols like OAuth 2.0, OpenID Connect, and SAML. The key decision factors are compliance requirements (e.g., FedRAMP, SOC 2), user base size, and integration complexity with existing applications.

Configuration involves registering each application (client) with the IdP. During registration, you provide callback URIs, choose grant types (e.g., authorisation code flow for web apps, client credentials for server-to-server), and define scopes. Scopes are permissions that the application requests, such as 'email' or 'read:orders.' The principle of least privilege applies here-only request scopes that are absolutely necessary.

One critical component is token validation. The resource server must implement robust token validation logic. For JWTs, this means fetching the IdP's public key from a well-known endpoint (e.g., https://your-idp/.well-known/openid-configuration) and verifying the token's signature using that key. The token's algorithm must match what is expected (e.g., RS256). You must check the 'iss' (issuer) claim to ensure the token came from the correct IdP and the 'aud' (audience) claim to confirm it is destined for your application.

Common issues include misconfigured redirect URIs (causing the IdP to reject the callback), expired tokens, and clock skew between systems. Always use UTC time and allow a small leeway (e.g., 30 seconds) for clock drift. Logging and monitoring are essential-capture token validation failures and unrecognised issuers to detect potential attacks. Finally, have a token refresh strategy. Access tokens typically have short lifetimes (15–60 minutes). Use refresh tokens to obtain new access tokens without re-authenticating the user, but store refresh tokens securely.

## Memory tip

Think of a 'T.C.', Trusted Certificate. The third party is like a trusted certificate that says 'this user is allowed.'

## FAQ

**What is the difference between third-party authorisation and third-party authentication?**

Third-party authentication is about verifying who you are (your identity). Third-party authorisation is about what you are allowed to do after your identity is confirmed. Many systems combine both into one flow, but they are separate concepts.

**Is third-party authorisation safe?**

It can be very safe if implemented correctly. The risks come from insecure token storage, improper validation, or trusting a compromised IdP. Always validate tokens, use HTTPS, and choose a reputable IdP with strong security practices.

**Can third-party authorisation be used for machine-to-machine communication?**

Yes. In machine-to-machine scenarios, the client application authenticates directly with the IdP using its own credentials (client ID and secret) and receives an access token without user interaction. This is the client credentials grant type in OAuth 2.0.

**What happens if the third-party IdP goes down?**

If the IdP is unavailable, users cannot start new sessions until it comes back. Existing sessions using cached tokens may still work depending on token expiry and caching policies. To mitigate this, you can implement token caching with short timeouts or have a backup local authorisation mechanism for critical functions.

**Do I need third-party authorisation for every application?**

Not necessarily. Small internal applications with simple access control might be fine with local authorisation. Third-party authorisation is most beneficial when you need centralised user management, SSO across multiple applications, or when you want to reduce the risk of storing credentials in many places.

**Is OAuth 2.0 the same as third-party authorisation?**

OAuth 2.0 is the most common protocol used to implement third-party authorisation, but it is not the only one. SAML is also widely used (especially in enterprise environments) and a custom protocol could technically serve the same purpose. In practice, when people talk about third-party authorisation, they are often referring to OAuth 2.0 or OpenID Connect.

**Can I still use my own user database with third-party authorisation?**

Yes. You can have your own user database as a fallback, or you can synchronise your users to the third-party IdP. Many organisations use Azure AD Connect to sync on-premises Active Directory to Azure AD, then use Azure AD for third-party authorisation. The IdP becomes the source of truth for authorisation decisions.

## Summary

Third-party authorisation is a security model where the decision to grant access to a resource is delegated to an external entity, known as a third-party identity provider (IdP). This approach separates the responsibility of user credential management and permission enforcement from the application itself, reducing the risk of credential theft and simplifying account management. Common protocols used include OAuth 2.0, OpenID Connect, and SAML 2.0.

The real-world value of third-party authorisation lies in its ability to support single sign-on (SSO), centralised user lifecycle management, and consistent access control policies across diverse applications. For IT professionals, understanding how tokens are issued, validated, and scoped is essential for designing secure systems. Common pitfalls include confusing authentication with authorisation, neglecting token validation, and underestimating the single point of failure risk from IdP downtime.

In certification exams, you will face scenario-based questions about federated identity, protocol comparisons, and troubleshooting access failures. Mastery of the OAuth 2.0 authorisation code flow, token validation steps, and the difference between authentication and authorisation will directly translate to higher scores. Remember that third-party authorisation is a tool-it does not replace the need for local security measures, but when implemented correctly, it strengthens overall system security.

---

Practice questions and the full interactive page: https://courseiva.com/glossary/third-party-authorisation