생활코딩 OAuth 정리

 

생활코딩 OAuth 정리

[출처:https://www.youtube.com/watch?v=hm2r6LtUbk8&list=PLuHgQVnccGMA4guyznDlykFJh28_R08Q-&index=1]

 

 

OAuth 에 등장하는 3개의 주체가 있다. 

- resource owner(user)

- resource server

- client

-(추가)Authorization server – 인증과 관련된 처리를 전담하는 서버

 

OAuth를 등록하는 방법

-       Client가 resource server를 이용하기 위해서는 resource server의 승인을 사전에 받아 놔야한다. 이것을 등록(register)라고 한다. 서비스 마다 다 다르다. 

공통적으로 받는것은

1.     Client ID  -> 우리가 만들고 있는 어플리케이션을 식별하는 식별자인 아이디

2.     Client Secret  -> client id 에 대한 비밀번호(id가 노출되더라고 절대 비밀번호는 노출되면 안된다!!. 엄청난 보안사고가 된다.) 

3.     Authorized redirect URls  -> resource server 가 권한을 부여하는 과정에서 Authorized code 라는 값을 전달을 할 것이다. 그 과정에서 어디로 전달 해 주세요~ 라고 resource server 에게 알려주는 것이다.

 

 

OAuth 인증받는 방법

-       Resource owner(user) 가 client에 접속 하는 과정에서 resource server 를 사용할 일이 있다? -> 그럼 client가 resource owner에게 ex)”카카오톡으로 로그인하기” 같은 화면을 보여준다.

 

 

버튼을 만들어 주는데 이 버튼은 별거가 아니다. 그냥 옆에와 같은 링크를 만들어 주면 된다. url에는 client id와 사용하고자 하는 기능 scope=B,C 그리고 redirect_url을 같이 링크로 제공해주면 된다.

 

이 다음은 resource owner가 resource server로 이 주소로 하게 되면 resource server가Resource owner가 현재 로그인이 되어 있는지 안되어 있는지를 확인해서 만일 안되어         있으면 로그인을 하라는 화면을 띄어준다. Resource owner가 로그인에 성공 했다면 resource server 는 그때서야 위에서 받은 url의 client id 와 같은 client id 가 server에 존재하는지를 확인한다. 그 다음에 그 client id에 해당하는 redirect url을 확인하고 넘겨온 redirect url과 같은지 또한 확인하다. 만약 다르면 작업을 끝내 버린다. 이를 통과하면 resource owner에게 scope에 해당하는 권한을 client에게 부여 할 것인지를 확인하는 메세지를 전송하게 된다. 허용 버튼을 누르면 허용 했다는 정보가 resource server 로 전송된다. Resource server는 resource owner 어떤 scope을 허용 하는지를 저장한다(파일 이나 데이터베이스로).  

 

앞에서는 이제 resource owner에 대한 허락을 획득 했으니 이제 resource server가 승인을 해줘야 한다.

-       먼저 resource server는 Access token을 부여하기 전에 authorization code를 resource owner에게 준다. 이때 주는 헤더값이 있는데 이를 사용자가 인식하지도 못하게 은밀하게 헤더 주소로 이동하게 된다. 헤더 주소에 포함된 code로 client는 authorization code를 알게 된다.

그 다음에 client는 resource server에 resource owner를 거치지 않고 직접 접근한다. 이때 접근 할 때 authorization code와 redirection url, client id, client seceret을 함께 보내는데 이를 resource server 가 자신이 가지고 있는 것과 비교를 하게 된다. 이것에 일치 하면 access token을 발급한다.

 

-       이제 access token 을 발급하기 전에 authorization code는 임무를 마쳣으니 resource server와 client에서 authorization code값을 지워 버린다.

 

-       이제 access token을 발급하고 resource server는 client로 이 access token 값을 응답해준다. Client는 내부적으로 access token을 저장한다.

 

API 사용하기

-       Resource server가 client에게 어떻게 해야지 자신을 사용할수 있을지를 알려준 것이다. (Application Programming interface)

-       직접 공식 사이트 가서 보면서 해보자!!

 

 

Access_token 은 수명이 있다..일반적으로 1시간 2시간 길게는 60일..

하지만 수명이 끝나면 API에 접속해도 데이터를 주지 않는다. 

그때마다 사용자에게 다시 발급받으라고 하기에는 너무 번거러울 것이다.

이때 사용하는 것이 refresh token

 

 

위의 그림에서 (F) 상황이 일어난다는 것은 Access Token의 수명이 끝낫다는 것을 의미 할 것이다.

그럼 refresh token을 Authorization server 에 전달 하면서 Access Token 을 다시 받는다.

 

Access token 만 갱신될 수도 있고 Access toeken 과 함께 refresh token 또한 갱신 되는 경우도 있다. 서버 마다 다르다.