Oauth-심화2

Ouath 단계

1.     첫 번째 웹사이트가 사용자를 대신해서 두 번째 웹사이트에 접속

è  이때 Oauth를 사용하고 , 사용자의 확인된 ID를 제공

2.     두 번째 사이트는 해당 트랜젝션 및 관여 당사자에 고유한 1회성 암호와 1회성 토큰을 생성

3.     첫 번째 사이트는 이 토큰과 암호를 사용자의 클라이언트 소프트웨어에 제공

4.     클라이언트 소프트웨어는 요청 토큰과 암호를 인증공급업체에 제시 ( 여기서는 두번째 사이트 or 다른 사이트 or 서비스 )

5.     인증 ( 인가 ) 공급업체에 인증이 되어 있지 않다면 , 클라이언트가 인증을 요청할 것이다.

인증 후에 , 클라이언트는 두 번째 웹사이트에 인증 트랜젝션 승인을 요청한다.

6.     사용자 or 소프트웨어는 첫 번째 웹사이트에서 트랜젝션을 승인

7.     그리고 사용자에게 승인된 액세스 토큰이 제공된다( 더 이상은 요청 토큰이 아니다 )

8.     사용자는 첫 번째 웹사이트에 승인된 액세스 토큰을 제공한다

9.     첫 번째 웹사이트는 사용자를 대신해서 인증에 대한 증명인 액세스 토큰을 두 번재 웹사이트에 제공한다.

10.  두 번째 웹사이트는 사용자를 대신해서 첫 번째 웹사이트가 사이트에 엑세스 할 수 있도록 허락한다.

11.  사용자는 트랜젝션이 성공적으로 완료된 것을 확인한다.

12.  Oauth는 최종 사용자를 대신해서 이런 방식으로 작동하는 첫 번째 인증/인가 시스템은 아니다. 유사하게 작동하는 인증 시스템이 많다 .

Oauth의 차별점은 여러 웹에서 작동을 하고 , 널리 도입되었다는 점이다 .

과거 다른 시스템과 달리 , 도입률을 높이는데 성공했다.

 

 Ex)

크게 3개의 구조

Web , app : 사용자의 예를 들어서 google의 캘린더의 정보를 가져와서

크게 클라이언트라고 정의할 수 있다.

è  Client

è  Resource Server 에 등록한다 . 우리의 서비스는 당신의 서비스를 이용할 것입니다.

è  Server는 Client에게 client ID , client secret을 부여한다.

è  Client는 이 정보를 저장해 놓는다.

è  Client가 사용자에게 부탁을 한다.

è  ~~ 사이트를 이용할 건데 인증을 해주세요라고

è  Google에 접속해서 사용할 수 있게 인증을 해주세요 ( 버튼과 같이 )

 

사용자

è  Resource owner

 

사용자의 정보를 가지고 있는 ( ex: google )  

è  Resource ( 데이터의 포괄적인 ) , Resource Server

 

 

과거

è  Owner 에게 ID와 PW 를 물어봤다 Server에

è  Client에 저장을 해놨다가 Server에 ID,PW를 줬다.

è  Server는 owner가 접속을 했다고 가정하고 알고있다.

è  엄청난 단점이 있다.

è  생명과도 같은 데이터를 누군지도 모르는 사람에게 줄 수 있다.