[스프링 시큐리티 Oauth2.0] Oauth2.0 동작방식

 

[소개]

 

Oauth2를 사용하기 위해서 Oauth의 흐름을 알아보도록 한다.

 

 

 

 

 

[Oauth2 사용자]

 

 

 

 

 

Oauth의 경우 총 4명의 사용자들을 정의 할 수 있다.

 

●  Resource Owner(사용자) :
일반적으로 사용자를 가르키며 소셜 서비스에 정보를 가지고 있는 사용자를 일컫는다.

즉 카카오톡이나 네이버 등의 해당 정보(회원가입)이 되어있는 사용자를 일컫음.

 

 

●  Client(자신의 웹사이트 혹은 웹사이트) 

 

● 사용자를 대신해 보호된 자원을 접근할 수 있는 어플리케이션이다.

 

● 클라이언트는 사용자로부터 권한을 위임받아 자원서버 (구글)에 접근한다.

 

● 클라이언트는 사용자 인증 후  , 인가 서버로부터 액세스토큰을 받아야 자원 서버에

접근할 수 있다.

 

 

●Authorzation Sever(인가 서버) -> 토큰이나 코드를 발급해주는 서버

 

● 클라이언트에게 토큰 , 코드를 발급해주는 서버다.

 

●사용자의 인증이 성공적으로 이루어진다면 , 인가 서버는 액세스토큰 혹은 코드를 클라이언트에게 제공한다.

 

 

 

●Resource Server (자원 서버 구글 , 네이버 , 카카오톡 등) 

 

●보호된 자원(예 사용자의 프로필 , 이메일 , 사진)등을 호스팅 하는 서버이다.

 

●클라이언트는 액세스 토큰을을 가져야만 이 Resource Server에 접근할 수 있다.

 

● 자원 서버의 예로는 캘린더 api , 날씨 api , 유저 정보 api 등등이 있다.

 

 

 

 

즉 이러한 형태로 각 역활이 정해져있다.

 

보통은 어떠한 흐름으로 흘러가냐면

 

 

-------------------프론트 채널------------------

 

1. 유저가 클라이언트 oauth 로그인을 한다.

 

2.로그인을 하면 해당 정보를 가지고 클라이언트는 인가 서버로 들어간다.

 

3.이 인가서버에서 아이디와 비밀번호가 일치한다면 코드를 보내준다

 

4.프론트에서 리다이렉트 경로를 백엔드 서버로 잡아서 백엔드로 코드를 보내준다.

 

---------------백엔드 채널 --------------------

 

1.코드를 받은 백엔드는 이 코드를 들고 인가 서버로 들어간다.

 

2.코드가 유효된 코드이면 인가서버에서 액세스 토큰을 발급해준다.

 

3.액세스 토큰(해당 사용자는 인증된 사용자)임을 표시하는 것이 액세스 토큰이다.

 

4. 액세스 토큰을 가지고 리소스 서버로 진입한다(구글 네이버 페이스북)등

 

5.액세스토큰을 주고 리소스 서버에서 해당 유저의 정보를 받아온다.

 

 

 

해당 부분이 각 리소스별 역활이다.

 

하지만 클라이언트가 해당 리소스로 액세스토큰을 받아오는 방법은 여러 유형이 있는데

이러한 유형들 6가지를 알아본다.

 

 

 

 

 

 

 

 

[Oauth 인증 플로우 ]

 

 

 

 

 

Oauth 권한 부여 유형은 총 6가지로 정의된다.

하지만 제일 많이 사용하는 방법이 1번째이고 스프링 시큐리티도 첫번째 방법을 사용한다.

 

 

 

 

 

 

 

[1단계 프론트 엔드 영역]

 

1.리소스 오너(사용자)는 클라이언트를 통해 oauth2 로그인을 한다.

 

2.로그인을 하면 해당 정보를 들고 인가 서버로 들어간다.

 

3.인가 서버에서 코드를 발급해준다.

 

4.코드를 발급받았다면 프론트는 백엔드 채널로 코드를 보내준다. (리다이렉트)

 

 

 

[2단계 백엔드 영역]

 

 

 

 

 

1. 프론트엔드로부터 받은 코드를 들고 인가 서버로 간다.

 

2.코드가 유효하다면 액세스 토큰을 발급해준다.

 

3.이 액세스 토큰을 들고 리소스 서버(구글 네이버)등으로 들어간다.

 

4.액세스토큰을 가지고 리소스 서버로가면 리소스 서버에서는 해당 유저의 정보를 준다.

 

 

 

 

 

 

해당 부분이 시퀸스 다이어그램이다.

 

해당 부분을 하나씩 설명하자면

 

1. 서비스 접속

 

● 사용자가 웹 사이트에서 Oauth (구글 로그인, 네이버 로그인)을 누른다.

 

 

 

2, authorization code(권한부여 코드 요청)

 

● 클라이언트는 사용자 브라우저를 통해 인가 서버에 Authorzation Code를 요청한다.

 

● 이 요청은 사용자 동의를 받기 위한 것임(Code 발급 X)

 

● reponse Type = code 와 함께 클라이언트 ID , 요청하는 스코프 , 리다이렉션 정보를 포함한다.

 

 

 

 

3. 로그인 페이지

 

 

 

●사용자 에겐 이러한 로그인 페이지가 보여진다.

 

 

 

4. 로그인 성공

 

●  사용자는 인가 서버에서 보여주는 로그인 페이지에서 자신의 크레덴셜(비밀번호를) 입력하여

로그인에 성공한다.

 

 

5.Conset(동의하기 페이지)

 

● 사용자는 클라이언트가 요청한 스코프(범위 프로필 정보 , 유저 이메일 ) 등에 대해 해당 범위에 정보를

허락할 것인지의 여부를 묻는다.

 

6.Conset(동의하기)

 

● 사용자가 동의하기 버튼을 누른다.

 

 

7. Authorzation Code 액세스 리다이렉트 

 

●  인가 서버는 사용자의 브라우저를 통해 리디렉션 Url로 Authentication Code를 보낸다.

 

● 이때의 리다이렉트 url은 백엔드 채널이다.

 

 

------------------------------ 백엔드 채널 ------------------------------------------

 

 

8.Access Token 요청 교환 

 

●  백엔드에서는 리다이렉트 경로를 통해 받은 Code를 사용하여

인가 서버에 접속하여 Acess Token을 요청한다.

 

●이 요청은 프론트에서 일어나는 행동이 아닌 백엔드 에서 일어나는 행동임.

 

 

9.Aceess Token + Refresh Token 응답

 

●인가 서버는 Code가 유효하다면 AcessToken을 발급해준다.

 

●백엔드 서버는 받은 Authorzation Code를 통해 AcessToken을 받아온다.

 

 

10.Acess Token으로 리소스 서버 API에 접근

 

● 해당 AcessToken을 가지고 있다면 리소스 서버(구글 네이버 카카오톡)등에 리소스 서버에 접근할 권한이 생긴다.

 

●이 AcessToken을 가지고 리소스 서버에 진입하여 유저의 정보를 요청한다.

 

 

11. Token 검증

 

● 리소스 서버는 해당 액세스 토큰이 유효한지 검증한다.

 

 

12. Token 검증 통과

 

● Token이 유효하다면 리소스 서버는 요청된 서버에 대한 자원에 접근을 허용한다.

 

13. 요청한 데이터 응답

 

●리소스 서버는 클라이언트에게 요청한 데이터를 응답한다.

 

 

 

[Oauth2 설정 정보 ]

 

그렇다면 인증 플로우에 대해서는 어느정도 봤다.

이제는 Oauth2를 사용하기 위해 설정 정보가 무엇을 의미하는지 보도록 하자.

 

 

 

[프론트 엔드 설정 정보 ]

 

 

 

 

1.response_type = code 

 

●이 피라미터는 클라이언트가 인증 코드를 사용하는 것을 인가 서버에 알리는 정보이다.

 

●code는 인가 서버에서 반환될 reponse 값을 code로 받을 것을 정의한다.

 

2. client - id 

 

●이 클라이언트 아이디는 인가 서버에 등록된 고유 식별자이다. 

 

●구글이나 네이버 등에서 oauth2를 사용시 클라이언트 아이디와 시크릿을 발급한다.

 

 

3.redirect_url(필수)

 

●이것은 인가 서버가 인증 코드를 보낼 url을 설정하는 것이다.

즉 정상적으로 로그인 성공까지 갔다면 이 코드를 백엔드 채널로 코드를 보내야하는데

그때의 리다이렉트 경로를 설정하는 것이다.

 

 

4.scope 

 

●클라이언트가 요청하는 액세스 범위를 나타내며 , 리소스 서버에 특정 범에 대한 접근 권한을 정의한다.

 

●즉 scope = profile , email로 설정한다면 클라이언트는 프로필과 이메일 정보만 접근할 수 있음을 나타낸다.

 

 

5.state 

 

●state는 CSRF의 공격을 방어하기 위해 만들어졌으며 클라이언트가 생성한 고유의 값임.

 

●state는 스프링 시큐리티 5.0에서 자동으로 지원되며 수동으로 설정할 수 없다.

 

 

 

 

------------------------------백엔드 ---------------------------------------

 

 

 

 

 

백엔드 채널부터는 직접적으로 인가 서버와 리소스 서버와 통신을 해야하기때문에

 

해당 설정부분은 인가 서버와 리소스 서버를 통신하기 위한 엔드포인트이다.

 

1. grant_type = authorzation_code

 

 

●이 피라미터는 클라이언트가 액세스 토큰을 요청하는데 사용되는 인증 방식을 지정한다.

 

●여기서는 grant_type = authorzation_code가 사용됨을 인가 서버에 알려주는 역활을 한다.

 

●해당 부분은 반드시 프론트에 설정한  grant_type과 같아야 한다.

 

 

2.code

 

●이 코드는 프론트엔드(클라이언트)에서 받은 code이다.

 

●이 코드를 통해 AcessToken을 받아야 한다.

 

 

3.redirct_url 

 

● 이것은 클라이언트가 처음 인증 코드를 요청할 때 사용한 리디렉션 url이다.

 

● 액세스 토큰 요청해서 이 url은 인증 코드와 함께 전송되어야 한다. 

 

반드시 인가 서버와 등록된 url경로와 일치해야 하고 프론트 엔드에 설정한

url경로와 반드시 일치 해야 함.

 

4. client_id

클라이언트 고유 식별자로 oauth 설정시 설정한 클라이언트 아이디와 일치해야한다.

 

5. client secret 

 

●클라이언트 시크릿은 클라이언트가 인가 서버와 통신할 때 사용하는 비밀 키이다.

 

●이것은 백엔드 서버에서 안전하게 보관되어야 하며 AcessToken을 받아올때

클라이언트 시크릿이 필요하다 .