📝OAuth 2.0이란
| Authentication | 사용자의 인증입니다 |
| Authorization | 사용자의 인가로 어떤 자원에 접근할 권한을 부여하는 것입니다 |
| Access Token | 리소스 서버에게서 리소스 소유자의 보호된 자원을 획득할 때 사용되는 만료 기간이 있는 Token입니다 |
| Refresh Token | Access Token 만료시 이를 갱신하기 위한 용도로 사용하는 Token입니다 |
📝OAuth 2.0의 4가지 역할
| Resource Owner | 사용자입니다. |
| Client | 보호된 자원을 사용하려고 접근 요청을 하는 애플리케이션입니다. 예) 쇼핑몰 홈페이지 |
| Resource Server | 사용자의 보호된 자원을 호스팅하는 서버입니다. 예) 구글 사용자 정보 관리 서버 |
| Authorization Server | 권한 서버. 인증/인가를 수행하는 서버로 클라이언트의 접근 자격을 확인하고 Access Token을 발급하여 권한을 부여하는 역할을 수행합니다. 예) 사용자 서버 |
📝 OAuth 2.0 추가 및 보완된 기능
- 1.0에 비해 구현이 쉬워졌습니다
- 웹, 앱 데스크톱 등 다양한 환경에서 지원이 가능해집낟
- 리프레시 토큰 개념이 추가 되었습니다
- HTTPS를 통해 암호화를 강화시켰습니다
📝 OAuth 2.0 프로토콜
Authorization Code Grant
가장 많이 사용하고 기본이 되는 방식입니다. 로그인한 이후에 권한 부여 승인 코드를 전달 받습니다. 해당 코드는 일회용이며 해당 코드로 Access Token을 요청한 이후에 받아서 원하는 자원에 접근하게끔 사용합니다.
Implicit Grant
권한 부여 승인 코드 없이 바로 Access Token을 발급합니다. 비교적 간소화 되기 때문에 빠른 응답이 있지만 Refresh Token이 사용 불가능하며(?) 안전하게 저장하기 힘든 클라이언트(JS 사용 브라우저)에 최적화된 방식입니다. → 서버가 없다는 거 자체가 이해가 안 된다.
Resource Owner Password Credentials Grant
username, password를 전달해 Access Token을 받습니다. 또한 Refresh Token이 사용이 가능합니다. 이 방식은 권한서버, 리소스 서버, 클라이언트가 모두 같은 시스템에 속해 있을 때 사용되어야하는 방식입니다. → Third Part를 사용 안 하고 내가 직접 인증서버를 관리할 때를 의미하는 거 같다
Client Credentials Grant
검증된 클라이언트 서버(예를 들면 쇼핑몰 웹서버)에서 자기는 안전하다고 판단한 경우에 사용됩니다. 이 경우에는 Resource Server는 사용자의 정보가 들어있는 곳보다는 모든 로그가 쌓여있고 필터링이 따로 필요 없는 서버를 접근하기 위한 것이고 이미 요청한 서버는 안전하다고 판단하기 때문에 Access Token을 요청하면 바로 해당 서버의 Acces Token을 바로 발급해주는 것입니다. Refresh Token은 사용할 수 없습니다.
📝 OIDC (Open ID Connect)
OAuth 2.0의 확장으로 Access Token으로 접근권한 뿐만 아니라 사용자 정보도 ID토큰으로 받아와 사용할 수 있습니다.
📝 개인적인 생각
위 프로토콜들이 이해가 안 되는게 많다 일단 로그인 처리가 되고 난 이후에 권한 부여 승인 코드를 따로 받는 것 그 이후에 그걸 가지고 Access Token을 굳이 또 요청해야하는 작업이 필요한 것일까? 로그인이 완료 되었으면 다 된 거 같은데 또한 Refresh Token을 못 쓴다는데 Refresh Token을 Access Token하고 같이 주면 되는 거 아닌가 싶다
🔗 참고 및 출처