Überblick über das OAuth2-Protokoll

Welcome to OAuth2! It's a widely used open standard for delegated authorization. This means it allows an application to access resources on behalf of a user without needing their actual credentials.

Think of it as giving a valet key to a parking attendant, instead of your master key. They can park your car, but can't open your house.

This is a crucial distinction! OAuth2 is primarily about authorization, not authentication.

• Authentication: Verifying who you are (e.g., logging in with username/password).
• Authorization: What you are allowed to do (e.g., access your photos).

OAuth2 helps you grant permission for an app to do things on your behalf, without telling the app who you are.

Imagine you want a photo printing service to access your pictures from Google Photos. Before OAuth2, you might have had to give the printing service your Google username and password.

This is risky! The service could then access your emails, documents, and anything else tied to your Google account. OAuth2 solves this by providing a secure way to grant limited access.

The Resource Owner is the person who owns the protected resources.

This is usually you, the end-user. You own your photos, your contacts, your profile information, etc., stored on various services.

You grant permission for applications to access these resources.

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 a desktop program. Examples include the photo printing service or a social media manager.

It needs your permission to do anything.

The Resource Server is where your protected resources actually live. It's the server that hosts the APIs for your data.

For example, if you're accessing Google Photos, the Google Photos API is the Resource Server. It protects your data and only allows access with valid tokens.

The Authorization Server is the heart of OAuth2. It's responsible for authenticating the Resource Owner and issuing access tokens.

When you grant permission, you're interacting with the Authorization Server. It then issues a special token to the Client, which the Client uses to talk to the Resource Server.

Instead of sharing your password, the Client Application receives an Access Token from the Authorization Server.

• This token is like a temporary, permission-specific key.
• It grants limited access to specific resources (e.g., read photos, but not delete them).
• It has an expiration time, enhancing security.

The Client presents this token to the Resource Server to get your data.

Here's a high-level overview of how it works:

1. You (Resource Owner) want to use an app (Client).
2. The Client asks you for permission to access your data.
3. You're redirected to the service provider (Authorization Server) to confirm.
4. You grant permission.
5. The Authorization Server gives the Client an Access Token.
6. The Client uses this token to request data from the Resource Server.

OAuth2 offers significant advantages:

• Enhanced Security: No password sharing, limited access tokens.
• User Control: You decide what data an app can access and for how long.
• Interoperability: A standard protocol widely adopted across the web.
• Reduced Risk: If a token is compromised, it has limited scope and lifespan.

It's the backbone of how many modern web services interact securely.

Which of the following best describes the primary purpose of OAuth2?

In this lesson, we explored the fundamentals of OAuth2. We learned it's a protocol for delegated authorization, allowing apps to access your resources without needing your password.

We identified the four key roles: Resource Owner (you), Client Application (the app), Resource Server (where data lives), and Authorization Server (grants tokens).

Next, we'll dive into how OpenID Connect builds on OAuth2 for identity.