[Security] OAuth2.0(인증, 인가)

인증(Authentication)과 인가(Authorization)

우리가 서비스를 만들 때 회원가입이라는 절차를 통해 사용자를 등록하고 관리하게 됩니다. 이때 사용자가 등록한 정보가 유효한 정보인지 인증(Authentication)하는 과정은 결코 쉽지 않고 복잡한 인증 프로세스를 요구하게 됩니다. 
 
이러한 문제를 해결하기 위해 우리는 사용자가 이미 가입한 거대 플랫폼 기업의 인증된 사용자 정보에 접근하여 정보를 얻어올 수 있습니다. 이때 사용하는 프로토콜이 바로 OAuth(Open Authrization)입니다. 
 
OAuth의 핵심은 사용자 정보를 가지고 있는 서버(구글, 카카오...)로부터 사용자 정보에 대한 접근 권한을
인가(Authorization) 받아 정보를 가져오는 것입니다. 
 
여기서 인가(Authorization)란 사용자에게 특정 리소스나 기능에 액세스 할 수 있는 권한을 부여하는 프로세스를 말합니다. 
 

OAuth2.0 Process

OAuth에 대해 4가지 주체를 중심으로 설명하겠습니다.

• Client(정보를 얻고자 하는 애플리케이션 서버)
• Resource Owner(정보의 당사자, 사용자)
• Authorization Server(권한을 부여해 주는 서버)
• Resource Server(사용자 정보를 가지고 있는 서버) 

1. Service Provider에 Client 등록

먼저 OAuth를 사용하기 전 해당 Resource의 Service Provider에 Client를 등록하여 id와 secret key를 발급받는 절차를 진행해야 합니다. 구글을 예시로 들면 아래 화면 같이 클라이언트 ID와 클라이언트 보안 비밀 코드를 발급받아야 합니다.

2. Client의 인증 요청 + 권한 부여 요청

사용자가 OAuth 로그인(구글)을 하게 되면 Client에서 Service Provider에 권한 부여를 위해 Resource Owner의 승인을 요청하게 됩니다. 권한 인증을 요청할 때는 처음에 등록한 Client Id와 사용할 리소스의 범위를 나타내는 Scope, 그리고 Resource Owner의 리소스 사용 승인 시 임시 토큰인 Authorization Code를 전달할 Readirect URI를 함께 파라미터로 넘겨줍니다. 예를 들어 Client Id가 hunbae, 접근할 정보가 email, name이고 redirect uri는 /auth/redirect라 하면, 쿼리 스트링으로 https://auth.google.com/profile?clientId=hunbae&scope=email,name&redirect_url=/auth/redirect 이렇게 나타낼 수 있습니다. 구글 같은 경우 아래와 같은 화면에서 인증요청을 하게 됩니다.

인증요청 UI

 

3. Authorization Code 부여

Resource Owner가 인증 및 권한 사용 승인까지 마치면, Service Provider의 인증 서버는 Token을 발행받기 위한 Authorization Code를 Client에게 전달해 줍니다. 이때 *302 상태 코드를 통해서 전달해 주게 됩니다.

 
* 302 코드는 URI를 Redirect 시켜 Response 헤더에 설정된 Location 필드에 있는 URI로 사용자를 이동시킬 수 있습니다.

 

4. Token 발행 요청 

Client는 Service Provider에게 Client Id, Secret Key, Authorization Code, Redirect URI를 넘겨주면서 Token 발행을 요청합니다. 그러면 대게 서버에서는 보내준 정보를 받아 RS256이나 HS256과 같은 방식(데이터 출처, 진위파악)으로  토큰을 발급해 줍니다. 이때 유효기간이 짧은 Access Token과 유효기간이 긴 Refresh Token을 발급해 줍니다. 보안성과 편의성을 위해 이와 같은 방식을 사용합니다. 
 

5. Resource 접근

 
발급받은 Access Token을 사용하여 Resource Server에서 사용자의 정보에 접근합니다. 이때 지정된 Scope에 접근하는 게 맞는지 확인 후에 정보를 넘겨줍니다. 
Authorization: Bearer <ACCESS TOKEN>과 같은 형식으로 요청 헤더에 세팅하여  요청을 진행할 수 있습니다.
 

6. Access Token 재발급

Access Token이 만료되면 같이 발급받은 유효기간이 긴 Refresh Token을 이용하여 Access Token을 재발급받을 수 있습니다. 만약 Refresh Token도 만료가 되면 위의 2번 절차부터 다시 진행하게 됩니다.
 

*토큰 파싱(Token parsing)

위와 같은 과정을 거쳐 정보를 얻어올 수도 있지만 Service Provider에 따라 발급해준 토큰 자체에 정보가 들어있어(JWT) 발급 받은 토큰을 파싱하여 정보를 추출하기도 합니다!

 
오늘은 이렇게 OAuth2.0에 대해 알아보았는데요 요즘처럼 개인정보에 대한 수집이 어려운 환경에서 꼭 알아두어야 할 기술인 것 같습니다. OAuth 프로토콜도 다른 것들과 마찬가지로 앞으로 보안성이 향상되는 방향으로 진화할 것 같습니다. 오늘 잠깐 나온 토근 발급 절차가 JWT(JSON Web Token)를 활용한 방식인데요. 다음에는 세션 유지 방식과 JWT에 대해 알아보도록 하겠습니다.  

** 틀린 내용이 있을 시 지적해 주시면 감사하겠습니다.