OAuth 2.0, OIDC(OpenID Connect)

OAuth2 .0을 사용하는 이유

인프런 예시

보통 간편로그인을 구현하고자 OAuth를 많이 사용한다.

 

먼저 OAuth를 사용하지 않고 구글 드라이브에 사진을 가져오는 예시를 생각해보자.

(사용자/구글/우리의 서비스->동구리닷컴)

 

1. 사용자가 구글(드라이브) ID/PW를 동구리닷컴 제공한다.

2. 동구리닷컴은 유저의 구글 ID/PW를 이용해서 구글에 로그인한다.

3. 동구리닷컴은 유저의 구글 드라이브에 저장된 사진을 가져온다.

 

위와 같이 동작하면 어떤 문제점이 있을까?

사용자 : 동구리닷컴이 구글 드라이브에만 접근한다고 신뢰할 수 없다.(구글 메일을 훔쳐본다면?)

동구리닷컴 : 사용자의 구글 ID/PW를 저장하고 직접 관리해야 한다.(탈취 당한다면?)

구글 : 사용자들의 구글 계정이 쉽게 유출될 수 있다.(구글의 잘못이 아닌데,,)

 

OAuth를 사용한다면 인증은 구글/카카오와 같은 플랫폼에서 진행하고,

제3자인 클라이언트(동구리닷컴)에게는 사용자의 정보에 접근할 권한만 위임할 수 있다.

사용자의 구글 ID/PW는 구글에서만 알고 저장하게 되는 것이다.

---

OAuth란?

먼저 인증과 인가의 차이점을 알아야 한다.

인증(Authentication) - 사용자의 신원을 확인하는 것

인가(Authorization) - 사용자가 어떤 리소스에 접근할 수 있는지, 어떤 동작을 수행할 수 있는지를 검증하는 것

인터넷 사용자들이 비밀번호를 제공하지 않고 다른 웹사이트 상의 자신들의 정보에 대해 웹사이트나 애플리케이션의 접근 권한을 부여할 수 잇는 공통적인 수단으로서 사용되는, 접근 위임을 위한 개방향 표준이다. - 위키백과 -

=> 구글/카카오와 같은 플랫폼에서 인증을 대신해주고 사용자 정보에 대한 접근 권한을 인가 받는 것이다.

---

OAuth 2.0 주체

구글/카카오 같은 플랫폼 입장에서 보면 용어를 이해하기 쉽다.

 

- Resource Owner

리소스 소유자, 즉 사용자이다.

ex) 구글 계정 소유자

 

- Client

플랫폼의 입장에서는 고객, 즉 리소스를 사용하려는 서비스이다.

Resource Server에게 리소스를 요청하고 응답 받는다.

ex) 동구리닷컴

 

- Authoization Server

인증과 권한을 부여해주는 서버이다.

사용자(=Resource Owner)는 여기로 ID/PW를 가지고 Authorization Code를 발급 받아 Client에게 전달한다.

Client는 여기로 Authorization Code와 Client 정보를 가지고 Access Token을 발급 받는다.

ex) 구글 OAuth 

 

- Resource Server

사용자의 리소스를 가지고 있는 서버이다.

Client는 Access Token과 함께 여기로 리소스를 요청하고 응답받는다.

ex) 구글 

 

Authorization Code(인증의 증거)

= 사용자가 권한을 위임했다는 증거로, 클라이언트에게 발급되는 임시코드

Access Token(인가된 권한)

= 클라이언트가 Resource Server로부터 사용자의 리소스를 접근할 수 있는 권한을 증명하는 토큰

---

OAuth 2.0의 인증방식

1. Authorization Code Grant(권한 부여 승인 방식)

• 가장 많이 사용되는 방식(간편 로그인에 사용)
• 권한 부여 코드 요청 시, 자체 생성한 Authorization Code를 전달하는 방식
• Refresh Token 사용 가능

 

2. Implicit Grant(암묵적 승인 방식)

• 권한 부여 코드 없이 사용자 자격 증명을 교환하는 방식
• Access Token을 url로 전달하기 때문에 Accesss Token 만료기간을 짧게 설정해야 함
• Refresh Token 사용 불가능

 

3. Resource Owner Password Credentials Grant(자원 소유자 자격 증명 승인 방식)

• 사용자의 ID/PW를 직접 사용해서 Access Token을 받아오는 방식
• 권장되지 않는 방식
• Refresh Token 사용 가능

 

4. Client Credentials Grant(클라이언트 자격 증명 승인 방식)

• 클라이언트의 자격 증명만으로 Access Token을 받아오는 방식
• 사용자가 아닌 클라이언트에 대한 인가가 필요할 때 사용하는 방식
• Refresh Token 사용 불가능

 

❗️ 1번 방법과 2번 방법이 차이점은 Authorization Code의 유무이다.

Authorization Code가 없이 바로 Access Token을 발급받는다면,

Authorization Server에서 Access Token을 전달할 방법이 redirect URI 밖에 없다.

redirect URI로 Access Token을 전달한다면 브라우저를 통해 노출되게 되는 문제가 생긴다.

---

OAuth2.0 동작방식(Authorization Code Grant 방식)

Resource Owner = 사용자

Client = 서비스 

 

- 로그인

1. 사용자가 '구글로 로그인하기' 버튼을 클릭한다.

 

2. 서비스는 Authorization Server로 로그인 요청을 보내는데,

Client ID, Redirect URI, Response Type, Scope를 포함해서 요청을 보낸다.

• Client ID : 클라이언트 자격 증명
• Redirect URI : 권한 서버가 요청에 대한 응답을 보낼 URI
• Response Type : 권한 부여 방식에 대한 설정(code로 설정)
• Scope : 클라이언트가 요청하는 권한(email, 캘린더 일정 입력 ..)

 

3. Authorization Server는 로그인 페이지를 사용자에게 제공한다.

 

4. 사용자는 로그인 페이지에 접속하여 ID/PW를 입력한다.

 

5-6. 인증이 완료되면 Authorization Server는 사용자를 Redirect URI로 리다이렉트하면서 Authorization Code를 전달한다.

URI에 Authorization Code가 포함되어 있기 때문에 클라이언트에게도 전달된다.

 

인증 과정에서는 Resource Owner <-> Authorization Server만 통신을 한다.

Client는 단지 로그인 요청만 보낸다.

 

- Access Token 얻기

7. 서비스는 사용자에게 받은 Authorization Code, Client ID, Client Secret, Redirect URI를 가지고

Authorization Server에게 Access Token을 요청한다.

 

8. Authorization Server는 서비스에 Access Token을 발급해주고, 서비스는 DB에 Access Token을 저장한다.

 

9. 로그인이 완료된다.

 

- 리소스 요청

10. 사용자가 리소스가 필요한 경우, 서비스에 요청한다.

 

11. 서비스는 Access Token을 가지고 Resource Server에 요청한다.

 

12. Resource Server는 Access Token을 검증한 후, 리소스를 서비스에 제공한다.

 

13. 서비스는 사용자에게 리소스를 제공한다.

---

백엔드 프론트엔드 역할 

어떻게 동작하는지 이해가 됐는데, 프론트엔드와 백엔드에서 각각 어떤 처리를 해야하는지 헷갈렸다.

 

프론트엔드

• 간편 로그인 버튼 클릭 시, Authorization Server로 로그인 요청
• 사용자 인증 완료 후, 리다이렉트로 이동시키기

 

백엔드

• Redirect URI로부터 Authorization Code를 수신
• Authorization Code와 Client Sercret을 이용해서 Access Token 요청/수신/저장
• Access Token을 사용해서 Resource Server에 리소스 요청

---

OIDC(OpenID Connect)

OIDC는 OAuth 2.0의 확장판으로 OAuth 2.0의 상위 계층에서 같이 사용되고, 

Access Token 뿐만 아니라 ID Token도 전달받는다.

Accesss Token : Resource Server에서 사용자의 권한을 확인하기 위해 사용

ID Token : 클라이언트에서 사용자 정보를 확인하는데 사용

 

=> Access Token은 "무엇을" 할 수 있는지를 나타내고, ID Token은 "누가" 인증되었는지를 알려준다.

---

OAuth 2.0 vs OIDC

OAuth 2.0의 주요 목적은 인가(Authorization)이고, OIDC의 주요 목적은 인증(Authentication)이다.

위에서도 말했듯이 인가는 권한을 부여하는 것이고, 인증은 사용자의 신원을 검증하는 것이라는 차이가 있다.

 

OAuth 2.0으로도 사용자의 정보를 가져올 수 있지만, OIDC를 사용할 때보다 2배의 통신을 해야 한다.

OAuth 2.0은 Access Token을 발급 받은 후, Access Token을 사용하여 사용자 리소스를 다시 요청해서 받아온다.

하지만 OIDC를 사용하면, Access Token과 함께 제공받은 ID Token을 복호화해서 사용자 정보를 가져오면 된다.

---

OIDC 인증 과정

• IDP(IDentity Provider) : 구글/카카오와 같은 간편 로그인 서비스 제공사
• RP(Relying Party) : 사용자를 인증하기 위한 주체(Client, 서비스)

기본적인 흐름은 OAuth 2.0과 비슷하다.

 

요청할 때 차이점은 다음과 같다.

• response_type에 "id_token"을 추가해야 한다.
• openid라는 특별한 scope를 무조건 포함시켜야 한다.
• profile, email 등의 scope를 사용해서 사용자의 프로필 정보나 이메일을 요청할 수 있다.