Get a high-level overview of the OAuth 2.0 authorization framework, its roles, and common grant types.
OAuth 2.0 is not an authentication protocol; it's an authorization framework. Its primary purpose is to enable a third-party application to obtain limited access to a user's resources on another service, without exposing the user's credentials (like their password) to the third-party app. Think of it as a valet key for your car: you can give the valet a key that only allows them to drive the car, not open the trunk or glove compartment. In the OAuth 2.0 world, there are four key roles: 1. **Resource Owner**: The user who owns the data and can grant access to it. 2. **Client**: The third-party application that wants to access the Resource Owner's data. 3. **Authorization Server**: The server that authenticates the Resource Owner and issues access tokens after getting their consent. 4. **Resource Server**: The server that hosts the user's data (the API) and accepts the access tokens. The process, known as a 'flow' or 'grant type', generally works like this: The Client redirects the user to the Authorization Server. The user logs in and gives consent. The Authorization Server redirects the user back to the Client with an 'authorization code'. The Client then exchanges this code (along with its own client ID and secret) with the Authorization Server to get an 'access token'. Finally, the Client uses this access token to make requests to the Resource Server to access the user's data. The most common grant type is the 'Authorization Code' grant, described above, which is ideal for traditional web applications. Other grant types exist for different scenarios, like the 'Implicit' grant for single-page apps and the 'Client Credentials' grant for service-to-service communication.