OAuth(Open Authorization)는 인터넷 사용자들이 비밀번호를 제공하지 않고 타사 서비스가 사용자 정보에 접근할 수 있도록 허용하는 개방형 표준. 주로 사용자가 애플리케이션과 데이터를 안전하게 공유할 수 있도록 설계되었다. OAuth의 주요 개념은 다음과 같다:
- Resource Owner (리소스 소유자): 보호된 리소스에 접근할 수 있는 권한을 가진 사용자이다. 예를 들어, Google 계정 사용자.
- Client (클라이언트): 리소스 소유자를 대신해 보호된 리소스에 접근하려는 애플리케이션. 예를 들어, 타사 애플리케이션(카카오톡, 페이스북 등)이다.
- Resource Server (리소스 서버): 보호된 리소스를 호스팅하는 서버이다. 예를 들어, Google 서버이다.
- Authorization Server (인증 서버): 클라이언트의 리소스 접근 요청을 인증하고 권한 부여 토큰을 발행하는 서버이다. 예를 들어, Google의 OAuth 인증 서버.
- Access Token (접근 토큰): 인증 서버가 클라이언트에게 발급하는 토큰으로, 클라이언트가 리소스 서버에 접근할 수 있도록 한다. 이 토큰은 일반적으로 만료 시간이 정해져 있다.
- Refresh Token (갱신 토큰): 접근 토큰의 유효기간이 만료된 경우, 새로운 접근 토큰을 발급받기 위해 사용하는 토큰. 일반적으로 접근 토큰보다 더 긴 유효기간을 가진다.
- Authorization Code (인증 코드): 클라이언트가 리소스 소유자의 동의를 받은 후에 인증 서버로부터 발급받는 코드이다. 클라이언트는 이 코드를 사용하여 접근 토큰을 요청한다.
- Scopes (범위): 클라이언트가 요청하는 리소스에 대한 접근 권한의 범위를 지정한다. 예를 들어, "email", "profile", "contacts"와 같은 세부 항목이 있을 수 있다.
OAuth 인증 흐름
- 사용자 인증 요청: 클라이언트가 리소스 소유자를 대신하여 인증 서버에 인증 요청을 보낸다. 이 요청에는 클라이언트 ID, 리디렉션 URI, 요청하는 범위 등이 포함된다.
- 사용자 동의: 리소스 소유자가 인증 서버에서 클라이언트가 요청한 권한에 동의한다.
- 인증 코드 발급: 인증 서버가 리소스 소유자의 동의를 확인하고 클라이언트에게 인증 코드를 발급한다.
- 접근 토큰 요청: 클라이언트가 인증 코드를 사용하여 인증 서버에 접근 토큰을 요청.
- 접근 토큰 발급: 인증 서버가 클라이언트에게 접근 토큰을 발급.
- 리소스 서버에 접근: 클라이언트가 접근 토큰을 사용하여 리소스 서버에 접근하고 보호된 리소스를 요청.
- 리소스 제공: 리소스 서버가 접근 토큰을 확인하고 보호된 리소스를 클라이언트에게 제공.
OAuth는 이러한 개념과 흐름을 통해 사용자 데이터의 안전한 공유를 가능하게 하며, 비밀번호를 제3자에게 노출하지 않도록 한다.
인터넷 사용자들이 비밀번호를 제공하지 않고 다른 웹사이트 상의 자신들의 정보에 대해 웹사이트나 애플리케이션의 접근 권한을 부여 할 수 있는 수단.
고객이 카카오에 로그인을 한다.
로그인이 최초라면 고객은 카카오에 유저네임과 패스워드를 서버에 보낸다
그리고 고객은 추가로 Scope를 추가로 보낸다.
Scope는 어느 정보까지 허용할 건지를 정하는 것이다 즉, 선택정보를 말한다(나이, 이메일 등등)
고객은 서버를 통해 서명을 넘기고 그 서버가 OAuth제공자에게 해당하는 서명을 던질 때 검증이 되었다면 이것을 OAuth라고 한다.
즉,
권한을 스프링서버가 위임을 받고, 그 서명을 OAuth제공자를 통해 전달하고 해당하는 정보를 전달 받으면 이 일련의 과정을 OAuth라고 한다.
서버 자체가 세션에 대한 정보를 저장하지 않고 토큰에 대한 정보를 검증만 하기 때문에 스프링서버는 토큰을 OAuth 검증 후 버리게 된다
왜 버리는 거지?’
토큰을 세션에 저장할 수 있지만 사용자가 늘어나면 서버가 늘어난다
늘어난 서버에는 내 토큰이 세션에 저장되어 있지 않기 때문에 세션에 저장하지 않고 버린다
그렇다고 토큰을 DB에 I/O를 하기 시작하면 서버에 부하가 걸린다.
OAuth가 끝나면 카카오에서 인정을 받은 사람이기 때문에 신뢰성이 확보가 된다.
때문에 서버는 카카오에 회원정보를 요청할 수 있다.
OAuth제공자는 반드시 신뢰할 수 있는 곳이어야 한다. 그리고 그 신뢰받았다는 것을 서버가 확인이 되면 OAuth 제공자는 더이상의 역할이 필요 없게 된다
그리고 서버와 고객은 토큰을 버리고 OAuth 제공자로 부터 제공받은 고객정보를 토대로 토큰을 만들어서 검증하고, 이 토큰을 통해서 작업을 수행한다.
코드방식
서버는 고객정보로 강제회원가입을 시키고 이 회원정보로 토큰을 만들고, 토큰을 고객에 주고 나중에는 토큰을 검증만한다 STATELESS다.
고객이 WEB 브라우저 상에서 서버에 로그인페이지를 달라고 요청을한다
그러면 서버는 로그인 페이지를 제공하는데 거기에 카카오 로그인페이지 버튼을 같이 제공한다.
기존에 로그인버튼을 눌러서 로그인을 요청하면 되지만
카카오 버튼을 클릭하는 순간 카카오로 다이렉트 요청을 한다(카카오 로그인 페이지 줘) 그러면 카카오는 로그인 페이지를 제공한다.
그럼 카카오 화면이 뜬다.
그 요청도 역시 카카오로 가고 카카오는 DB에서 아이디를 확인하고 검증을 한다. 그러면 카카오는 토큰이 아니라 임시 코드(랜덤)를 제공한다.
카카오는 헤더에 로케이션을 제공하고
상태 코드로 302(리다이렉션)을 준다.
브라우저는 상태코드를 보면서 로케이션 키값을 확인하고 그 주소를 다시 스프링서버로 보낸다.
(302 PROTOCOL 참고)
그리고 이 코드를 다시 카카오로 전달하면 카카오는 검증을 하고 토큰을 다시 제공한다
토큰은 서버에서 가지고 있는 것이 안전하다.
크리덴셜 방식
만약에 휴대폰 앱이라면 서버에 로그인을 요청을 할 필요가 없다
앱을 설치를 받았다면 이미 그림을 받았다는 것이다
카카오 로그인을 하게되면 휴대폰 앱의 SDK를 통해 카카오에 요청을 보내고 카카오로 부터 토큰을 받는다.
그리고 전달 받은 토큰을 다시 서버측에다 토큰을 전달하고 토큰을 전달받은 서버는 그 토큰을 다시 카카오로 전달해 회원정보를 요청받는다
서버는 토큰을 받으면 해당 정보로 강제회원가입을 하고 그 회원가입된 정보로 다시 토큰을 생성하고 카카오와의 연결을 삭제한다.
Share article