OAuth2-Rollen und -Terminologie

Welcome! OAuth2 involves several key players working together. Understanding each role is crucial to grasp how it secures access to your data without sharing your password.

Let's meet the main characters in the OAuth2 story!

The Resource Owner is typically you, the end-user. You own the protected resources (like your photos, contacts, or profile information) stored on a service.

• You grant permission to applications to access your resources.
• You never directly share your password with the application.

The Client Application (or just "Client") is the application that wants to access your protected resources. This could be a mobile app, a web application, or even another server-side application.

• It needs your permission to act on your behalf.
• It doesn't store your credentials.

The Authorization Server (AuthZ Server) is the core of OAuth2. It's responsible for:

• Authenticating the Resource Owner (you).
• Obtaining your consent for the Client.
• Issuing access tokens to the Client.

Think of it as the trusted authority that manages permissions.

The Resource Server is where your protected resources actually live. This is the API server that holds your photos, emails, or other data.

• It receives requests from the Client.
• It validates the access token presented by the Client.
• If the token is valid, it grants access to the requested resources.

Here's a simplified look at how these roles interact:

1. The Client asks the Resource Owner for permission.
2. The Resource Owner interacts with the Authorization Server to grant consent.
3. The Authorization Server gives an access token to the Client.
4. The Client uses this token to request resources from the Resource Server.

Let's say you use a "Print My Photos" app (Client) to print pictures from your Google Photos (Resource Server).

Instead of giving the app your Google password, Google (Authorization Server) asks you if the app can access your photos. You say "Yes," Google gives the app a special token, and the app uses that token to get your photos.

When the Authorization Server issues an access token, it's like giving the Client a temporary, specific key.

• This key only unlocks certain resources (defined by "scopes").
• It has a limited lifespan.
• If lost, it doesn't expose your main password.

We'll cover tokens in more detail later!

OAuth2 builds a chain of trust:

• The Resource Owner trusts the Authorization Server to handle their consent.
• The Client trusts the Authorization Server to issue valid tokens.
• The Resource Server trusts the Authorization Server to verify tokens it receives.

This allows secure delegation without password sharing.

Consider a mobile banking app that wants to display your transaction history from your bank's API.

Which OAuth2 role represents the mobile banking app?

In this lesson, we identified the four fundamental roles in OAuth2:

• Resource Owner: The user who owns the data.
• Client Application: The app requesting access.
• Authorization Server: Manages user consent and issues tokens.
• Resource Server: Hosts the protected data and validates tokens.

Understanding these roles is vital for grasping OAuth2's secure delegation model. Next, we'll look at the different ways these roles interact through "grant types"!