Spring Boot OAuth 2.0

OAuth 2.0 ?

웹 사이트 계정 인증에 타 서비스의 계정을 사용하는 인증 방식

---

1. oauth를 사용하는 세 개의 주체

client

• 리소스 서버에 접속해서 자원을 가져가는 대상
• resource owner와 resource server 중간에서 해당 정보를 받아 로그인을 대신 처리하는 역할
• 내 웹/앱

resource server

• 제어하고자하는 자원을 가진 서버
• ex) 구글, 카카오, 네이버

resource owner

• 자원의 소유자 (서비스를 이용하는 유저)
• ex) 구글 사용자

 

ex) client(서비스)는 resource owner(사용자)를 대신하여 로그인 하는데,

  이때 필요한 정보를 resource server(구글)에서 얻어 서로 비교하여 유효성을 판단한다.

 

-> 기존 유저가 자신의 id, password를 입력해서 로그인하는 대신,

 client가 유저의 로그인 정보(resource)를 resource server(카카오)에 요청해 대신 로그인 한다.

(쉽게 말해서 나 대신 client가 로그인 해주는거. 내 수고를 덜어줌)

 

 

위의 과정을 위해서는 client가 2가지 단계를 거친다.

1. Resource Owner(유저)의 허용

->유저의 정보를 대신 사용하기 때문

 

2. Resource Server(구글)로 부터 client 신원확인

->client가 정말 유저 본인인지 확인하기 위하여 client를 구분하는 code 전달

 

---

2.OAuth 등록시 필요한 정보

Client ID

• 식별자 ID
• 외부에 노출 가능
• resource server 입장에서 어떤 서비스인지 구분하는 ID

Client Secret

• 비밀번호 개념
• 외부에 노출 절대 불가능 (보안상의 문제 발생)

Authorized redirect URIs

• 리소스 서버가 권한을 부여하는 과정에서 Authorized code 값을 전달해 줄 때 이 주소로 전달해 달라는 의미
• client<->resource server 유효성 검사에서 redirect URIs도 체크, 해당주소가 아닐경우 client가 아니라고 판단
• 콜백함수는 client를 판별하는 수단 
• ex) Location : http://client/callback?code=3

 

---

3. Resource Owner 승인과정

1. 사용자(resource owner)는 서비스(client)에서 '페이스북 글 쓰기'를 하려고 한다. '글쓰기'버튼을 눌렀다고 가정. 그때 서비스(client)는 팝업창 제공한다.
2. passport.js가 만들어준 Login with Facebook 링크를 Resource Owner가 클릭 할 때, 현재 로그인 상태가 아니라면 Resource Server로 부터 로그인 창을 보여준다.
3. 로그인이 완료되면 client가 사용하려는 기능(scope)에 대해 Resource Owner의 동의(승인)을 요청한다.
4. Resource Owner가 Allow 버튼을 누르면 Resource Owner에게 권한을 위임했다는 승인이 Resource Server전달된다. 이로써 Resource Owner의 정보가 저장된다.
5. client는 Resource Owner가 대신 로그인과 더불어 여러기능(scope) 사용해도 된다는 승인을 받는다.

 

Resource Server가 갖는 정보는?

1. Client Id : Resource Owner와 연결된 client가 누군지
2. Client Secret: Resource Owner와 연결된 client의 비밀번호
3. Redirect URL : (진짜)client와 통신할 통로
4. user id : client와 연결된 Resource Owner의 id
5. scope : client가 Resource Owner 대신에 사용할 기능들

---

4. Refresh token

client가 매번 Access token 얻는 것은 매우 복잡하고 일정기간이 지나면(expiration date) (토큰) 사용 할 수가 없다.

이를 해결하기 위해 Refresh token이 이를 돕는다.

 

accessToken

회원들의 아이디와 비밀번호를 모르는 상태로 회원들을 식별할 수 있는 기능들을 구현할 수 있다.

 

---

OAuth를 이용하는 목적은 API를 제어하는 것이다.

Access Token을 부여받은 client는 Resource Server의 API를 호출해 유저의 정보를 사용 할 수 있다.

 

 

 

+ 더 추가 예정