[WEB] OAuth란?

OAuth란?

OAuth란 Open Authorization의 약자로

인증을 중개해주는 구조다.

우리가 웹이나 앱에서 자주 접하는 소셜 로그인 방식을 생각하면된다.

(OAuth2.0이라는 기술로 구현하고 있다.)

다시 말해 이미 사용자 정보를 가지고 있는 웹 서비스(네이버, 카카오 구글, 페이스북 등)에서 사용자 인증을 대신해주고

접근 권한에 대한 토큰을 발급해서 이 토큰으로 다른 서버에서 인증이 가능하다.

 

OAuth를 이용하면 뭐가 좋을까?

OAuth는 이용자와 개발자 모두에게 좋은 점이 있다.

먼저 이용자 입장에서 장점은 무엇일까?

 

유저는 웹 상에서 많은 서비스를 이용하고 있고 각 서비스를 이용하기 위해선 회원 가입 절차가 필요한 경우가 많다.

이 때 OAuth를 활용한다면 자주 사용하는 구글이나 네이버 같은 서비스의 아이디와 비밀 번호를 기억하면

다른 서비스를 이용할 수 있기 때문에 모든 서비스의 아이디와 비밀번호를 기억해야할 필요가 없다.

또한 보안상의 이점도 있다. 검증되지 않은 App에서 OAuth를 이용해 로그인했을 때

유저의 민감한 정보가 직접 App에 노출 되지 않고 인증 권한에 대한 허가를 미리 구해야하기 때문에

더 안전하게 이용할 수 있다.

 

그렇다면 개발자에게 좋은 점은 뭐가 있을까?

OAuth를 이용하면 신규 회원 가입이나 회원 관리를 신경쓰고 있지 않아도 되기 때문에 편하다.

앞에서 살펴보았던 유저들의 장점이기도 하지만 보안상의 이점 또한 개발자들에게도 장점이 되지 않을까?

 

오 지금까지 살펴본 바로는 OAuth가 대세라는 것을 알았다.

그렇다면 OAuth는 어떠한 방식으로 작동하는 걸까?

 

OAuth의 작동 메커니즘

OAuth의 주체

1. Resource Owner

-OAuth 인증을 통해 소셜 로그인을 하려는 사용자를 일컫는다.

 

2. Resource Server & Authorization Server

-사용자가 소셜 로그인을 하기 위해 사용할 서비스(구글 네이버 등)의 서버 중 사용자의 정보를 저장해 놓은 서버를 말한다.

-이미 사용중인 서비스의 서버 중 인증을 담당하는 서버를 Authorization Server라고 한다.

 

3. Application

사용자가 소셜 로그인을 활용해 이용하고자하는 새로운 서비스는 환경에 따라 조금씩 다르게 부른다.

여기서는 Application이라고 하자.

경우에 따라 Application을 Client와 Server로 세분화하기도 한다.

 

OAuth 인증 방식의 종류와 흐름

OAuth 인증 방식에는 여러 종류가 있다.

그 중 Implicit Grant Type, Authorization Code Grant Type, Refresh Token Grant Type 세 가지만 알아보겠다.

(Grant Type은 Authorization Server에서 Access Token을 받아오는 방식을 말한다.)

 

1. Imlicit Grant Type

 

1. 사용자가 Application에 접속한다.

2. Application에서 Authorization Server로 인증 요청을 보낸다.

3. Authorizaiton Server는 유효한 인증 요청인지 확인한 후 액세스 토큰을 발급한다.

4. Authorization Server에서 Application으로 액세스 토큰을 전달한다.

5. Application은 발급받은 액세스 토큰을 담아 Resource Server로 사용자의 정보를 요청한다.

6. Resource Server는 Application에게서 전달 받은 액세스 토큰이 유효한 토큰인지 확인한다.

7. 유효한 토큰이라면, Application이 요청한 사용자의 정보를 전달한다.

 

하지만 소셜 로그인을 할 때 Implicit Grant Type은 잘 사용하지 않는다.

왜냐하면 기존 서비스에 로그인을 해놓기만 하면 새로운 서비스에 바로 엑세스 토큰을 내어주기 때문이다.

(바로 토큰을 내어주면 보안에 취약할 것이다.)

그렇기에 일반적으로 사용하는 방법은 Authorization Code Grant Type을 사용한다.

 

2.Authorization Code Grant Type

1. 사용자가 Application에 접속한다.

2. Application에서 Authorization Server로 인증 요청을 보낸다.

3. Authorizaiton Server는 유효한 인증 요청인지 확인한 후 Authorization Code를 발급한다.

4. Authorization Server에서 Application으로 Authorization Code를 전달한다.

5. Application이 Authorization Code로 발급받은 Authorization Code를 전달한다.

6. Authorizaiton Server는 유효한 Authorization Code인지 확인한 후 액세스 토큰을 발급한다.

7. Authorization Server에서 Application으로 액세스 토큰을 전달한다.

8. Application은 발급받은 액세스 토큰을 담아 Resource Server로 사용자의 정보를 요청한다.

9. Resource Server는 Application에게서 전달 받은 액세스 토큰이 유효한 토큰인지 확인한다.

10. 유효한 토큰이라면, Application이 요청한 사용자의 정보를 전달한다.

 

10 단계의 걸친 과정을 Implicit Grant Type과 비교해보자.

Authorization Code를 사용한 인증 단계를 추가했기 때문에 비교적 안전하다.

또한 아래의 그림과 같이 Application Client에 노출 시키지 않고 Server에서만 관리하도록 만들 수 있기에

소셜 로그인을 구현하는 방식의 선택지가 많아진다.

 

그런데 사용자가 새로운 서비스를 이용하다가 Access Token이 만료 됐다고 가정해보자.

Access Token이 만료될 때마다 새롭게 다시 발급 받아야한다면 사용자 편의성은 떨어질 것이다.

그래서 Access Token을 발급할 때 Refresh Token을 같이 발급해주기도 한다.

이 때 Refresh Token을 사용해서 Access Token을 받아오는 인증 방식을 Refresh Token Grant Type이라 한다.

 

3. Refresh Token Grant Type

Refresh Token Grant Type은 간단하다.

Authorization Server로 Refresh Token을 보내주면 Authorization Server는 Refresh Token을 검증한 다음 Access Token을 다시 발급해준다.

Application은 다시 발급 받은 Access Token을 사용해 Resource Server에서 사용자의 정보를 받아온다.

 

 

OAuth의 장점

1. 쉽고 안전하게 새로운 서비스를 이용할 수 있다.

- 사용자는 OAuth를 통해 특정 사이트에 회원 가입을 할 때 클릭 몇번으로 손쉽게 가입이 가능하다.

- 정보를 해당 서비스에 직접 노출 하는 것이 아니기에 직접 가입하는 것보다 보안상 강력하다.

- Application 입장헤서도 회원의 정보를 직접 가지고 있을 때 발생할 수 있는 회원 정보 유출 위험성을 낮출 수 있다.

 

2. 권한 영역을 설정할 수 있다.

- OAuth 인증을 허가한다고 해서 새로운 서비스가 사용중이던 서비스의 모든 정보에 접근이 가능한 것은 아니다.

사용자는 원하는 정보에만 접근을 허락할 수 있다.

 

- OAuth 설정 페이지에서는 Application에서 필요한 정보를 선택할 수 있다.

사용자는 이 중 원하는 정보만 선택적으로 제공할 수 있다.