OAuth 와 JWT의 흐름

OAuth 란

- 사용자가 비빌번호를 노출하지 않고 다른 웹 사이트의 자신의 정보를 웹이나 애플리케이션에 접근 권한을 부여할 수 있는 개방형 표준.

- 로그인 뿐만 아니라 데이터 접근 권한도 포함하고 있기 때문에, Authentication(인증)뿐만 아니라 Authorization(인가)도 포함하고 있다.

- Resource owner

User(보호된 자원에 대한 엑세스 권한을 부여할 수 있는 사용자)

- Client

OAuth를 이용하기 위해 Resource 서버에 등록한 애플리케이션이나 웹 서비스.

- Resource server

허용할 수 있는 보호된 리소스를 호스팅하는 서버, 엑세스 토큰을 사용하여 보호된 리소스 요청에 응답합니다.

- Authorization server

성공적으로 인증을 마친 클라이언트에게 엑세스 토큰을 발급하는 합니다.

* 공식 표준 문서에는 Resource server와 Authorization server를 구분짓지만, 일반적으로 Resource server하나로 통용하기도 합니다.

1. Resource Owner이 Client에 로그인 요청

2. Client는 Resource Server에 Authorization Code 요청

3. Resource Server가 Client에게 Authorization Code발급

4. Client는 Authorization Code를 이용하여 다시 Resource Server에게 토큰 요청

5. Resource Server는 Authorization Code가 올바르다면 Access Token, Refresh Token 발급

6. 이제 Access Token을 이용해서 Resource Server에 데이터를 요청하고 검증이 완료되면 Resource서버는 Client에게 scope 범위의 데이터를 응답

 

JWT

- 토큰 기반 인증 시스템은 세션을 사용하는 서버 기반 인증 시스템과 달리 클라이언트가 서버에 접속을 하면 서버에 해당 클라이언트에게 인증되었다는 의미로 '토큰'을 부여한다.

- 토큰을 발급받은 클라이언트는 서버에 요청을 보낼때마다 header에 토큰을 담아서 보낸다 

- 그럼 서버에서는 클라이언트로부터 받은 토큰을 서버에서 제공한 토큰과 일치여부를 체크한다

 

토큰의 장점

무상태(stateless)이며 확장성(scalability)입니다.

이 개념은 토큰 기반 인증 시스템의 중요한 속성입니다. 토큰은 클라이언트 사이드에 저장하기 때문에 완전히 stateless하며, 서버를 확장하기에 매우 적합한 환경을 제공합니다. 만약에 세션을 서버측에 저장하고 있고, 서버를 여러대를 사용하여 요청을 분산하였다면, 어떤 유저가 로그인 했을땐, 그 유저는 처음 로그인했었던 해당 서버에만 요청을 보내도록 설정을 해야합니다. 하지만 토큰을 사용한다면 어떤 서버로 요청이 들어가던 상관이 없습니다.

보안성

클라이언트가 서버에 요청을 보낼 때, 더 이상 쿠키를 전달하지 않음으로 쿠키를 사용함으로 인해 발생하는 취약점이 사라집니다. 토큰을 사용하는 환경에서도 취약점이 존재할 수있으니 언제나 취약점에 대비해야합니다.

확장성

토큰을 사용하여 다른 서비스에서도 권한을 공유 할 수 있습니다. 예를 들어서, 스타트업 구인구직 웹서비스인 로켓펀치에서는 Facebook, LinkedIn, GitHub, Google 계정으로 로그인을 할 수 있습니다. 토큰 기반 시스템에서는, 토큰에 선택적인 권한만 부여하여 발급을 할 수 있습니다. (예를들어서 로켓펀치에서 페이스북 계정으로 로그인을 했다면, 프로필 정보를 가져오는 권한은 있어도, 포스트를 작성 할 수 있는 권한은 없습니다.)