Understanding OAuth2: How Access Tokens Secure User Data

This guide walks developers through the OAuth2 workflow, illustrating how users, client applications, resource servers, and authorization servers interact via access tokens to securely protect and grant access to user data, and highlights the critical steps of token issuance and validation.

21CTO
21CTO
21CTO
Understanding OAuth2: How Access Tokens Secure User Data
Reading guide: This article briefly explains how OAuth2 works, enabling developers to easily understand the scenarios where OAuth2 is applied and the specific problems it solves.

OAuth2 is a framework that secures user data by using access tokens. The process involves three main roles: the Resource Server, the Client Application, and the Authorization Server.

OAuth2 Workflow Overview

1. Users own their own data

2. A server that manages user data, called the Resource Server

3. A client application wants to use the user data

4. The Resource Server provides an API to deliver user data

5. The client app requests the API to obtain user data

6. The Resource Server returns the user data

7. What if a malicious client tries to act?

8. The malicious client also requests the Resource Server API

9. The Resource Server returns data to it as well

10. The malicious client easily obtains the user data

11. A security mechanism is needed to protect user data

12. Best practice: the client should use an Access Token to prove permission

13. The client must present its token when requesting the API

14. The Resource Server extracts the token from the request

15. The Resource Server validates the token

16. After successful validation, the Resource Server returns user data

17. This mechanism assumes the client has obtained a token beforehand

18. Someone must issue the token

19. Who issues the token?

20. The token issuer is the Authorization Server

21. The client interacts with the Authorization Server

22. The Authorization Server generates the token

23. Then the token is issued to the client

24. Review: three roles – Authorization Server, Client Application, Resource Server

25. Authorization Server generates token

26. The generated token is given to the client

27. Client uses token to request Resource Server API

28. Resource Server extracts token from the request

29. Authorization Server validates the token

30. If the token is valid, user data is returned

31. Before issuing a token, the Authorization Server must obtain user consent

32. Client requests a token from the Authorization Server

33. Authorization Server asks the user whether to grant permission

34. If the user agrees...

35. The Authorization Server generates a token

36. Then it is issued to the client

37. The key part is highlighted (yellow area)

38. This part shows the token request and acquisition process

39. This is the process standardized by OAuth2

Conclusion

The above outlines the background of OAuth2. The framework focuses on the "request token, issue token" portion of the security authentication process. OAuth2 defines four grant types to handle token acquisition, which will be described in detail later.

Compiled by: Du Yishu Source: https://medium.com/@darutk/the-simplest-guide-to-oauth-2-0-8c71bd9a15bb
Original Source

Signed-in readers can open the original source through BestHub's protected redirect.

Sign in to view source
Republication Notice

This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactadmin@besthub.devand we will review it promptly.

SecurityOAuth2access_tokenAuthorization ServerResource Server
21CTO
Written by

21CTO

21CTO (21CTO.com) offers developers community, training, and services, making it your go‑to learning and service platform.

0 followers
Reader feedback

How this landed with the community

Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.