OAuth2.0 - AccessToken, Role, Register

3가지 point가 존재

예를 들면 사용자가 Service에 접속해 글을 작성하거나 글을 봤다고 가정하면 해당 Service 사용자를 대신해서 Their(구글,페이스북, 트위터) 구글과 같은 서비스에 캘린더에 날짜 기록을 한다던지, 또는 페이스북에 글을 썼다거나 글을 봤다는 걸 공유 해준다던지 이러한 것들을 하기 위해서는 Service에서 User로 부터 User가 사용하고 있는 Their Service에 접근할 수 있도록 허가를 받아야한다.

 

일단 Their Service에  사용자의 Id, Password가 존재할 것이다. 그것을 User로 부터 전달 받아 Service에서 User의 Id, Password를 기억하고 있다가 실제로 User를 대신해서 Their Service에 접속할 때 기억한 Id,Password를 사용한다.

이것은 아주 간단하고 Their Service의 모든 기능을 사용할 수 있게 해주기 때문에 아주 강력한 방법이다.

 

하지만 이것은 많은 위험성을 내포하고 있다. User입장에서는 Their Service를 처음 보는 Service에 맡겨야 하는 것이다.하지만 처음 보는 Service를 신뢰할 수 있을까?  X

 

accessToken

OAuth를 사용하면(통해) User 요청에 의해 Their Service가 Id, Password 대신 access Token이라고하는 일종의 비밀번호의 대체제를 발급한다.

 

• User의 Id, Password가 아니라는 장점
• Their Service가 가지고 있는 모든 기능이 아니라 그중에 Service에 필요한 필수 적인 기능만 부분 적으로 허용하는 비밀번호의 대체제
• Their Service의 accessToken을 Service가 OAuth를 통해 획득한 다음 그 accessToken을 통해 Their Service에 있는 User의 데이터를 가져오거나 수정 또는 생성하고 삭제하는 작업을 할 수 있다.

OAuth의 이러한 장점을 이용하면 아예 처음부터 User의 Id, Password를 Service가 보관하지 않고 User를 식별할 수 있는 기능 구현할 수 있다.

 

Role

이 3자간의 관계가 OAuth의 핵심이라고 할 수 있다. 근데 OAuth 공식 메뉴얼을 보면 Authorization Server 라고 하는 서버가 한대더 있다. 이때 Resource Server는 데이터를 가지고 있는 서버이고, Authorization Server는 인증과 관련된 정보를 전담하는 Server이다. 공식 메뉴얼에서는 이 두가지를 구분하지 이 둘을 합쳐 Resource Server라고 더 간략하 정리할 수 있다.

 

Register

Client가 Resource Server를 이용하기 위해서는 Resource Server의 승인을 사전에 받아 두어야한다. 이것을 Register(등록)이라고 

 

3가지 공통요소

보통은 Resource Server가 될 Service마다 등록 방법이 다르지만 공통적이 것이 존재한다.

• Client ID - Client App을 식별하는 식별자 Id이다.
• Client Secret - 식별자 Id에 대한 비밀번
• Authorized redirect URIs - Resource Server가 권한을 부여하는 과정에 AuthorizedCode라는 것을 부여해준다. 그때  AuthorizedCode를 전달 받을 URL을 지정한 것이다. 이때 다른  Authorized redirect URIs을 통해 전달 받을 것을 요청 받으면 Resource Server는 이를 거부한다.

위 3가지 요소가 그것이다.