OAuth(Open Authorization)

OAuth?

위의 사진은 삼쩜삼 앱에 첫 화면이다. 아이디, 비밀번호를 통해서 로그인/회원 가입을 하는 것이 아닌 카카오 계정을 통해서 로그인/회원 가입을 대신한다.

즉, 사용자 인증을 카카오의 사용자 인증 방식으로 사용하겠다는 것이다.

이 때 OAuth가 사용된다. OAuth는 삼쩜삼 앱이 카카오의 특정 유저의 데이터에 접근할 수 있는 권한을 위임 받게 해준다.

 

OAuth는 인증을 위한 개방형 표준 프로토콜로 다양한 플랫폼(구글, 네이버, 카카오)의 특정 사용자 데이터에 접근하기 위해 제 3자 클라이언트(우리 서비스)가 사용자의 접근 권한을 위임 받을 수 있게 한다.

이를 통해서 외부 어플리케이션에서 연동되는 서비스에서 일부 제공하는 기능들을 사용할 수도 있다.

 

OAuth 사용 이유?

OAuth를 사용하지 않으면 아이디, 비밀번호 등 사용자는 처음 보는 서비스에 개인정보를 제공해야 서비스를 이용할 수 있다. 사용자 입장에서는 안전한지 모르는 서비스에 개인정보를 제공하는 것이 부담스러울 수 있다.

서비스를 운영하는 측에서는 사용자의 개인정보를 다 가지고 있다가 보안에 문제가 생겨서 유저들의 개인정보가 유출이 되면 책임을 져야 하는 부담이 있다.

이러한 이유들 때문에 개인정보 같은 민감한 것들은 믿을 만한 큰 기업에 맡기고, 큰 기업에서는 해당 정보에 접근할 수 있는 권한만 발급해주는 OAuth가 생겨났고, 사용되고 있다.

 

초기에는 구글은 AuthSub, 야후는 BBAuth 등 각 회사가 개발한 방식을 사용했다. 근데 이렇게 되면 표준화가 되지 않아서 각 회사에 연동하기 위해서는 개별적으로 개발해야 했다.

이렇게 표준화 되지 않은 문제를 해결하기 위해서 OAuth가 등장하였다. 초기 버전인 1.0이 2006년에 개발되었지만 이를 여러 방면에서 개선한 2.0 버전이 2012년에 등장하였다.

2.0으로 넘어오면서 모바일에서 사용하기 더 편해졌다.

 

OAuth 주체

• Resource Owner
• ⇒ 사용자
• Authorization Server & Resource Server
  • Authorization Server는 Resource Owner(사용자)를 인증하고, Client에게 Access Token을 발급 해 주는 서버 ex) 구글, 카카오, 페이스북…
  • Resource Server는 리소스를 가지고 있는 서버 ex) 구글, 카카오, 페이스북…

공식 표준 문서에는 Authorization Server와 Resource Server를 구분 지었지만 보통은 Resource Server 하나로 통용하기도 한다.

• Client
• ⇒ 우리가 개발하는 서비스

 

OAuth 흐름

등록

OAuth를 사용하려면 먼저 Resource Server에 Client를 등록해야 한다.

• Client ID (애플리케이션 식별자)
• Client Secret (애플리케이션 식별자에 대한 비밀번호) Client ID, Client Secret은 Access Token을 발급 받는데 사용된다. Client Secret은 절대 공개되면 안됨!
• Redirect URL (Client ID, Client Secret 확인 후 redirect 할 주소, Authorization Code를 전달할 주소) 인증에 성공한 사용자는 등록된 Redirect URL로만 리다이렉션 되는데 이러한 이유는 등록되지 않은 URL로 리다이렉션 되는 경우 중간에 Authorization Code를 탈취 당할 위험이 있기 때문이다. Redirect URI는 기본적으로 보안을 위해 https만 허용된다. 단, 루프백(localhost)은 예외적으로 http가 허용된다.

 

인증

인증에는 4가지 방법이 있다.

1. Authorization Code Grant
2. Implicit Grant
3. Resource Owner Password Credentials Grant
4. Client Credentials Grant

이 중에서 Authorization Code Grant 방법이 웹이나 앱에서 가장 많이 사용된다.

 

1. Authorization Code Grant

간편 로그인 기능에서 사용되는 방식으로 클라이언트가 사용자 대신 특정 유저의 정보에 접근을 요청할 때 사용되는 방식이다.

인증이 되면 Authorization Server에서 Resource Owner로 Access Token을 바로 발급해주는 것이 아니라 Authorization Code를 발급 해주는 방법이다. Resource Owner는 Authrorization Code로 Access Token을 발급 받아서 사용하게 된다.

위의 그림과 같이 동작하게 된다.

2 ~ 3의 과정은 자동? 으로 진행 된다. Authorization Server에서 검증을 하고 인증할 수 있는 사용자이면 등록 시에 받았던 Redirect URL로 리다이렉션 시키면서 Authorization Code를 같이 전달한다. 이렇게 하는 이유는 위에서 언급 했던 것 처럼 등록되지 않은 URL로 리다이렉션 될 경우 Authorization Code를 중간에 탈취 당할 위험이 있기 때문이다.

5 ~ 6 과정 둘 다 Access Token, Refresh Token을 발급 한다고 되어있는데 두 과정에서 발급되는 토큰은 다른 토큰이다. 과정 5의 토큰은 Client가 Resource Server에 요청할 때 사용할 토큰이고, 과정 6의 토큰은 Resource Owner가 Client에 요청할 때 사용할 토큰이다.

 

2. Implicit Grant 

자격 증명을 안전하게 저장하기 힘든 클라이언트에 최적화 된 방식이다.

이 방식에서는 Authorization Code 없이 Access Token이 바로 발급된다. 이러한 점 때문에 Acceess Token 보안 문제가 발생할 수 있어서 Access Token의 만료 기간을 짧게 설정한다.

Authorization Server는 Client secret를 통해서 사용자를 인증하지 않는다. 이러한 점 때문에 Access Token 발급을 위한 절차는 간소화 되어 효율성이 좋아지는 장점이 있지만 Access Token이 url로 전달되어 탈취 당할 수 있는 단점도 존재한다.

 

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

아이디, 비밀번호를 이용하여 Access Token을 발급 받는 방식이다.

클라이언트가 타사의 프로그램이 아닌 경우에 사용한다. 즉 Client, Authorization Server, Resource Server가 모두 같은 시스템인 경우에 사용한다.

 

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

Client의 자격 증명으로 Access Token을 발급 받는 방식이다.

Client가 관리하는 리소스 또는 권한 서버에 해당 Client를 위한 제한된 접근 권한이 설정된 경우에 사용된다.

이 방식은 자격 증명을 안전하게 보관할 수 있는 Client에서 사용되어야 한다.

 

참고

https://hudi.blog/oauth-2.0/

https://woodcock.tistory.com/17

https://velog.io/@max9106/OAuth

https://cheese10yun.github.io/oauth2/