Original link: http://www.cnblogs.com/linianhui/p/permission-based-access-control.html
OAuth2 and OIDC (OpenId Connect), whose role is authorization and authentication. So when we get the Access Token of OAuth2 or the Id Token of OIDC, how does our resource service verify whether these tokens have permission to perform an operation on the resource?
For example, I have an API, /books, which has the following 5 operations:
- POST /books to add a book
- GET /books/{id} to get a book
- PUT /books/{id} to update a book
- DELETE /books/{id} deletes a book
- GET /books to get a list of books
Its pseudocode is as follows:
[Route("books")]
public class BooksController : Controller
{
[HttpGet("")]
public Book[] Get() { return null; }
[HttpGet("{bookId}")]
public Book Get(int bookId) { return null; }
[HttpPost("")]
public Book Post(Book book) { return null; }
[HttpPut("{bookId}")]
public Book Put(int bookId, Book book) { return null; }
[HttpDelete("{bookId}")]
public Book Delete(int bookId) { return null; }
}
So let's take a look at how OAuth2-based Access Token, OIDC's Id Token and traditional role-based permission control handle operations to control these resources.
1 Scope of Access Token of OAuth2
We all know that the final product of OAuth2 is to provide us with an Access Token, and this Access Token contains a Scope field, which represents which resources the authorization server or resource owner grants the third-party client to allow to operate the resource server. range .
One thing to note here is that,
This authorization process can have the participation of resource owners (Authorization Code, Implicit, Resource Owner Password Credentials Grant),
It is also possible without his participation (Client Credentials Grant).
Then based on the resources of the above books, we can define a Scope of book_manager to control the permission control of the five operations of books.
Then the Scope-based permission control for Books looks like this:
[Route("books")]
public class BooksController : Controller
{
[HttpGet("")]
[Scope("book_manager")]
public Book[] Get() { return null; }
[HttpGet("{bookId}")]
[Scope("book_manager")]
public Book Get(int bookId) { return null; }
[HttpPost("")]
[Scope("book_manager")]
public Book Post(Book book) { return null; }
[HttpPut("{bookId}")]
[Scope("book_manager")]
public Book Put(int bookId, Book book) { return null; }
[HttpDelete("{bookId}")]
[Scope("book_manager")]
public Book Delete(int bookId) { return null; }
}
Note that the bolded text adds a Scope description for each operation. If the Access Token has the scope of book_manager (regardless of which authorization method of OAuth2 it is issued, our final code part only recognizes the scope), then the calls to these APIs are allowed, otherwise it is regarded as unauthorized.
2 Sub of OIDC's Id Token
Please refer to Id Token for the purpose of Id Token and what information it contains. The difference between Id Token and Access Token is that it must contain the identity sub of a certain user, but there is no Scope . This is because the purpose of Id Token is to authenticate who the current user is, so the user must exist; because it is only for authentication , it will not include authorization-related things such as what operations the authenticated user can do. So for Id Token, how should our API manage permissions? The usual . The implementation details will not be explained. Its model is roughly: an entity (user or organization) has a set of roles, and each role represents a set of permissions. Does it feel similar to Scope? Actually, it's almost the same. Let's define such a role librarian. This is deliberately separate from the naming of Scope, because its source is different, so when we finally implement it, it will be independent.
[Route("books")]
public class BooksController : Controller
{
[HttpGet("")]
[Scope("book_manager")]
[Role("Librarian")]
public Book[] Get() { return null; }
[HttpGet("{bookId}")]
[Scope("book_manager")]
[Role("Librarian")]
public Book Get(int bookId) { return null; }
[HttpPost("")]
[Scope("book_manager")]
[Role("Librarian")]
public Book Post(Book book) { return null; }
[HttpPut("{bookId}")]
[Scope("book_manager")]
[Role("Librarian")]
public Book Put(int bookId, Book book) { return null; }
[HttpDelete("{bookId}")]
[Scope("book_manager")]
[Role("Librarian")]
public Book Delete(int bookId) { return null; }
}
If the user represented by sub has it or the organization to which it belongs (no matter how it is organized and managed, we can finally know whether the user has a certain role) the role of librarian. Then it is allowed to access these operations of books.