OAuth2 & OpenID Connect Deep Dive · 课时

刷新令牌与作用域

学习刷新令牌如何在无需重新进行身份验证的情况下获取新的访问令牌,以及作用域在定义访问权限中的作用。

第 2 / 4 课11 个步骤

刷新令牌与作用域 是 CoddyKit 上的免费 OAuth2 & OpenID Connect Deep Dive 课时。 这是第 2 节课,共 4 节。 你可以在下方免费阅读本课时的完整内容 — 然后在浏览器中使用内置代码编辑器和全天候 AI 导师进行实践。 这是 OAuth2 & OpenID Connect Deep Dive 学习路径的一部分,你的进度在网页和 CoddyKit 应用中同步。 OAuth2 & OpenID Connect Deep Dive 课程共包含 4 节课。

本课时的部分内容尚未翻译,以英文显示。

Keep Your Apps Authorized

Imagine using an app that needs to access your online photos. It gets permission, but what if that permission expires after just an hour?

You'd have to log in again and grant permission every single time! That's not a great user experience, is it?

The Short Life of Access Tokens

Access tokens are like temporary keys. They grant access to specific resources (like your photos) for a short time, often minutes or hours.

This short lifespan is a crucial security feature. If an access token is stolen, an attacker has a limited window to use it, reducing potential damage.

Introducing Refresh Tokens

To solve the constant re-login problem, OAuth2 uses refresh tokens. Think of them as a special, long-term key.

An application uses a refresh token to quietly request a brand new access token from the Authorization Server without needing you to re-enter your credentials.

The Refresh Process

When your access token expires, the client application sends its refresh token to the Authorization Server. This happens in the background.

If the refresh token is valid, the server issues a new access token (and sometimes a new refresh token too!). Your app continues working seamlessly.

public class RefreshExample {
  public static void main(String[] args) {
    System.out.println("1. Access token expires.");
    System.out.println("2. Client sends refresh token.");
    System.out.println("3. Authorization Server validates.");
    System.out.println("4. New access token issued.");
    System.out.println("5. App continues without re-login.");
  }
}

Protecting Refresh Tokens

Since refresh tokens can grant new access tokens, they are very powerful and must be protected carefully. They are more sensitive than access tokens.

  • Store securely: Encrypt them or keep them in secure, HTTP-only cookies.
  • Revoke: If compromised, they must be immediately revoked by the user or server.
  • Limited use: Some systems issue new refresh tokens with each refresh, invalidating the old one.

What Are Scopes?

Now let's talk about scopes. Scopes are simple strings that define the exact permissions an application is requesting from you.

They control *what* an application can do with your resources once it has an access token. Think of them as permission labels, like 'read_email' or 'write_photos'.

How Scopes are Applied

When an app asks for your permission (during the authorization step), it will explicitly list the scopes it needs.

You, the resource owner, then decide which of those permissions to grant. For example, you might grant 'read_profile' but deny 'write_posts'.

Practical Scope Examples

Scopes are typically defined by the Resource Server, and their names can vary. Here are some common examples you might encounter:

  • openid: Requesting basic identity info (often used in OpenID Connect).
  • profile: Access to your basic profile data (name, picture, etc.).
  • email: Access to your primary email address.
  • https://www.googleapis.com/auth/photos.readonly: Read-only access to Google Photos.

Scopes Persist on Refresh

When an application uses a refresh token to get a new access token, the new access token will generally carry the same scopes that were originally granted.

The application can't magically gain new permissions during a refresh; it must request them again through a full user authorization flow if it needs more access.

Quick Check: Tokens & Scopes

Which of the following statements about Refresh Tokens and Scopes are TRUE?

Summary: Refresh & Scopes

We've covered two vital OAuth2 concepts that enhance both security and user experience:

  • Refresh Tokens: Long-lived credentials used to obtain new, short-lived access tokens without user interaction, improving UX.
  • Scopes: Granular permissions that define what an application is authorized to do on a user's behalf.

Understanding these helps you build more secure and user-friendly applications!

免费开始

用 AI 导师学习 OAuth2 & OpenID Connect Deep Dive — 免费

在浏览器中编写并运行真实代码,获得全天候 AI 导师的即时帮助,并在网页或应用中继续学习。

课程
12
课程
48

常见问题解答

「刷新令牌与作用域」课时是免费的吗?

是的 — 「刷新令牌与作用域」的完整文本可在网页上免费阅读。要进行交互式练习(内置代码编辑器和全天候 AI 导师)并解锁 OAuth2 & OpenID Connect Deep Dive 课程的其余内容,请升级到 CoddyKit PRO。 OAuth2 & OpenID Connect Deep Dive 课程共包含 4 节课。

「刷新令牌与作用域」这节课中我会学到什么?

学习刷新令牌如何在无需重新进行身份验证的情况下获取新的访问令牌,以及作用域在定义访问权限中的作用。 你通过在浏览器中直接运行的动手代码来练习 OAuth2 & OpenID Connect Deep Dive,全天候 AI 导师会在你学习这节课的过程中回答你的问题。

学习 OAuth2 & OpenID Connect Deep Dive 需要有经验吗?

无需任何先前经验。CoddyKit 上的 OAuth2 & OpenID Connect Deep Dive 课程适合初学者到高级学习者,你可以从这里开始或从头开始,按照自己的节奏学习。 这是第 2 节课,共 4 节。

「刷新令牌与作用域」课时需要多长时间?

大多数 CoddyKit 课程大约需要 5–10 分钟。每节课都很精短且互动,所以你能稳步进步,并在网页和应用中从离开的地方继续。

我能在这节 OAuth2 & OpenID Connect Deep Dive 课中编写并运行代码吗?

能。每节 OAuth2 & OpenID Connect Deep Dive 课都包含内置代码编辑器,你可以在浏览器中直接编写并运行真实代码,并获得即时 AI 反馈 — 无需本地设置。

此课程中的所有课时

  1. 面向公共客户端的 PKCE
  2. 刷新令牌与作用域
  3. 资源所有者密码凭据
  4. 令牌交换(RFC 8693)
← 返回 OAuth2 & OpenID Connect Deep Dive