Authentication과 Authorization
둘다 리소스에 대한 액세스를 컨트롤한다.
Authentication (인증)
유저의 신원을 확인한다. (로그인으로)
Authorization (인가)
유저가 권한을 가지고 있는지 확인한다.
로그인 된 유저마다 가지고 있는 권한이 다를 수 있다.
- 예) 일반 사용자와 관리자는 접근할 수 있는 정보가 다를 수 있다.
OAuth 2.0 와 OpenId Connect
OAuth 2.0
OAuth 2.0은 유저가 애플리케이션과 credentials을 공유할 필요 없이 애플리케이션이 유저를 대신하여 리소스에 액세스할 수 있도록 표준화된 방법을 제공하는 Open Authorization Protocol 이다.
여기에서 애플리케이션은 OAuth 로그인을 사용하고 있는 애플리케이션을 뜻한다. 리소스는, OAuth를 제공하는 구글, 네이버, 혹은 카카오로 이해하면 된다. 그리고 credentials는 주로 id, password이다.
그래서 이 프로토콜을 통해, 애플리케이션은 리소스 (예를 들면 구글 드라이브, 구글에 있는 연락처) 를 접근할 수 있다.
OAuth 2.0 에 참여하는, party (한국말로 당사자 ? 주체 ?) 가 있다. 구글 드라이브와 어플리케이션으로 예를 들어 보겠다.
Resource Owner
구글 드라이브의 소유자는? 유저 자신일 것이다. 유저를 뜻한다.
Client
OAuth 2.0 프로토콜을 사용하는 클라이언트다. OAuth 2.0 을 사용하는 애플리케이션이 되겠다.
Resource Server
구글 드라이브의 서버, 구글이다.
Authorization Server
구글이다. OAuth 2.0 의 authorization을 해주는 서버이다.
OAuth 1.0
OAuth 1.0 은 2007년에 발표된 OAuth의 초기 버전이다. 웹 어플리케이션이 유저의 credentials 없이 유저를 대신해서 리소스에 엑세스를 제공하는 표준화된 프로토콜이다. 지금 우리가 쓰는 것은 OAuth 2.0이고, OAuth 2.0 은 OAuth 1.0 과 호환되지 않으므로, 같은 일을 하는 새로운 프로토콜이라고 보면 되겠다.
OpenId Connect (OIDC)
OAuth 프로토콜 위에서 동작하는 Authentication 프로토콜이다. 사용자가 identity provider (IdP) (구글)를 사용해 어플리케이션(인터뷰 뱅크)에 인증할 수 있게 한다. OIDC는 OAuth 2.0에 사용자 프로필 정보 등을 포함한 ID token을 추가해 클라이언트 에서 사용자 정보를 바로 알 수 있도록 한다.
요약하자면, OAuth 2.0 은 리소스에 대한 액세스 권한을 부여하는데 사용되며, OIDC는 사용자 인증에 사용된다. OAuth 2.0 도 물론 사용자 인증에 사용될 수 있지만, OIDC는 인증만을 위해 설계된 프로토콜이다.
어떻게 적용하나?
프런트 서버와 백엔드 서버가 분리된 환경에서의 적용을 살펴본다. 클라이언트는 프런트와 백을 모두 포함하므로, 어디에서 이를 구현하는지는 상관이 없다. 구체적으로는 해당 프로토콜에서 이를 명시하고 있지 않다. 그래서 다음과 같이 사용할 것이다.
구글
네이버
네이버의 경우, OIDC 는 제공하지 않고있다. 따라서, ID Token을 디코딩해서 유저 정보를 가져오는 것이 아니라, 백에서 Auth Server로 프로필 조회 요청을 한번 더 거치게 된다.
번외
인증이 안되어있을 때, 왜 401 Unauthorized 를 사용할까?
Authorization은 인가고, 유저의 권한을 확인한다면서, 왜 authentication이 안됐을 때 401을 사용할까?
클라이언트가 특정 리소스에 접근하는데 authentication이 안되어 있어 unauthorized 인 상태를 의미한다.
따라서 authenticated가 안되어 있을 때는 401 Unauthorized, 권한이 없을 때는 403 Forbidden을 사용해야 한다.
Reference
'네트워크' 카테고리의 다른 글
| DNS Lookup (0) | 2023.07.29 |
|---|---|
| AWS VPC, Region과 Zone (0) | 2023.06.09 |
| Restful API (1) | 2023.05.31 |
| SSH (0) | 2023.05.23 |
| Session vs JWT (1) | 2023.01.26 |
