'Who is making request?'에 대한 답은 얻었지만 'What can that person do?'의 답을 해주지는 않는다. 우리는 모든 사람에게 같은 데이터를 주고 싶지 않다. 어느 데이터는 누군가에겐 민감한 정보이기 때문이다. 어떤 action은 해당 abiltiy를 가진 사람만이 할 수 있도록 해야한다.
Our API server can check to see can the user that's been authenticated perform the requested action.
Who is making request? --> for securing our system
What can that individual do? --> Authorization
어떤 사람이 identified 됐다고 가정하면 db에서 데이터 검색과 같은 action을 수행할 수 있도록 허용한다. 여기서 새로 추가된 step은 그 사람이 원하는 action을 수행할 수 있는지에 대한 질문을 하는 것이다.
우리의 목표는 Authorization으로 특정한 사람이 특정한 action을 수행하지 못하도록 막는 것이다.
한가지 사물(thing)에 대해서 그에 관련된 여러가지 actions가 있다.
Role에 따라 access를 제한할 수 있다. 해당 role에 할당된 사람이 많을수록 수행할 수 있는 actions은 적어진다. 항상 그렇다는 것은 아니지만 많은 사람들에게 민감한 정보에 대한 접근을 주지 않으려는 이유에서다.
Role에 각각 pemissions를 지정할 수도 있고 user에 직접 permissions을 할당함으로써 role을 overriding 할 수 있다.
User와 Role 테이블을 따로 만들면 좋은 이유는 Role의 permissions에 변경사항이 생겼을 때 pemissions만 수정하면 각각의 user에게 자동으로 적용되기 때문이다. 또한 user객체에 직접 pemissions를 추가할 수도 있다. 만약 sara가 special consumer라서 items를 post할 수 있는 상황이라고 가정한다면 sera의 pemissions에 ['post:items']를 추가해주면 된다.
유효한 identity인지 확인 후 token을 unpack하면 그 안에 pemssions이 들어있고
Endpoint에서 user의 permission object에 action에 필요한 pemission이 존재하는지 간단하게 확인할 수 있다.
Permission check 전에 validation step을 먼저 해야하는 것을 명심할 것.
((Defining Roles in Auth0, Using RBAC(Role-Based Access Control) in Flask, Restriction Features in Frontend는 영상으로 확인하기))