OAuth 1.0
OAuth는 사용자들은 Consumer에게 Provider상의 인증 정보를 제공할 필요 없이, Consumer에서 Provider의 개인 데이터로의 접근을 허용하는 방법을 제공하는 인증 위임 프로토콜
Consumer에게 실제 ID와 비밀번호가 전달되지 않고 Provider에 제공하면 Provider에서 Consumer에게 인증 토큰을 제공하는 방식
3-legged OAuth
[프로세스 요약]
컨슈머는 CK,CS를 이용해 RT,RTS를 응답받는다.
컨슈머는 사용자를 Provider가 제공한 Redirect Authorization page로 이동시킨다.
사용자는 provider에 컨슈머를 인가한다.
사용자가 클라이언트를 승인했음을 증빙하는 정보 Verifier(Code)를 가지고
클라이언트, Callback(Redirect_uri)에 갖고 간다.
CK,CS,RT,RTS,Verifier를 통해 AT,ATS를 요청하여 받는다.
그러면 기존의 RT,RTS는 폐기되고 AT,ATS로 컨슈머가 교체한다.
그러면 컨슈머는 CK,CS,AT,ATS를 통해서 리소스에 접근한다.
*CK(Client Key), CS(Client Secret), RT(Request Token), RTS(Request Token Secret), AT(Access Token), ATS(Access Token Secret)
[상세 설명]
Request Token을 요청할때 Consumer는 Provider로 Request Token을 요청한다.
요청 방식은 헤더를 통하거나 쿼리 스트링을 통하여 요청이 가능하다.
인증 과정시 프로토콜은 HTTPS 권장사항이다.
요청 정보로는
- oauth_version : 미지정시 1.0으로 기본값, 옵션사항
- oauth_signature_key : Consumer 임을 인증하기 위한 정보(사전에 Provider에게 받아야 함)
- oauth_signature_method : HMAC-SHA1 또는 RSA-SHA1
- oauth_callback : Authorize URL에 접속하여 사용자가 허용을 누르면 Redirect 시킬 URL 경로
- oauth_nonce : 요청이 한번만 사용되도록 확인하기 위한 값. 리플레이 공격 대책을 위한 파라미터 같은 요청을 반복하여 보낼 수 없음
- oauth_timestamp : nonce를 제한된 시간 동안만 보관할 수 있도록 하기 위한 값, 1970/1/1 00시부터 현재까지 초 값
- oauth_signature : 앞의 값을 CS로 서명한 값. 다른 정보의 위변조 검증이 목적
Provider가 Request Token을 응답할때
Http Body를 통하여 응답한다.
응답 정보로는
- oauth_token : 발급된 RT
- oauth_token_secret : 발급된 RT에 대한 Secret
- oauth_callback_confirmed : oauth_callback이 확인되었음을 의미한다. bool타입
Consumer는 사용자에게 인증을 위해 Service Provider로 이동시킨다.
- Authorization URL로 RT와 함께 Redirect 시킴
Authorization URL에서 로그인 후 승인 페이지로 이동한다.
승인 페이지에서 사용자는 Consumer가 Provider로 접근하는것을 승인한다.(인증 위임)
Provider는 사용자에게 Send Redirect 정보를 전달한다.
Send Redirect 정보
- oauth_token : authorize 요청시 RT값
- oauth_verifier : 검증 코드(사용자가 인증을 위임했다는 정보)
사용자는 Provider로 받는 RT와 Verifier를 Consumer에게 전달한다.
Consumer는 Provider에게 AT를 요청한다.
AT 요청시 요청정보
- oauth_consumer_key : CK
- oauth_token : RT
- oauth_signature_method : 서명 방식(HMAC-SHA1 등)
- oauth_verifier : 사용자에게 전달받은 Verifier
- oauth_nonce, oauth_timestamp
- oauth_signature : 시그니처
Provider는 요청받은 정보를 시그니처를 통해 위변조를 확인하고 AT를 응답한다.
응답정보
- oauth_token : Access Token
- oauth_token_secret : ATS
- 기타
Consumer는 이제 Rquest Token을 폐기하고 Access Token으로 대체한다.
Consumer는 사용자에 요청이 오면 필요에 따라 Provider에 Resource 접근하여 로직을 처리한다.
Resource 접근시 필수 요청 정보
- oauth_consumer_key : CK
- oauth_token : AT
- oauth_signature_method, timestamp, nonce
- oauth_signature : CKS와 ATS로 생성한 서명
3-legged OAuth의 단점
3-legged OAuth는 브라우저 기반이기 때문에 브라우저 기반 클라이언트가 아닌 경우는 사용하기가 힘든 문제가 있습니다.
2-legged OAuth
이를 해결하기 위해 XAuth가 있는데 이는 사용자의 Provider 계정과 암호를 요청 파라미터에 실어 보내는 방법으로 Consumer가 사용자의 ID와 PW를 알게되는 보안상 문제가 발생합니다.
최근 모바일에서는 XAuth보다 oauth_callback을 oob로 설정하고 요청하는 방식을 주로 사용합니다.
oob에 대한 설명은 아래를 참조해주세요.
https://www.rfc-editor.org/rfc/rfc5849
https://redcoder.tistory.com/112
'Languege > Java & Spring' 카테고리의 다른 글
[JPA] DynamicUpdate 안되는 문제 (0) | 2022.11.08 |
---|---|
[Spring Framework OPEN API서비스 교육] OAuth 2.0 (0) | 2022.10.18 |
[Spring Framework OPEN API서비스 교육] 1.API KEY란? (0) | 2022.10.04 |
[스프링 에러] 카카오 로그인 시 발생 오류 및 해결방법 Provider ID must be specified for client registration 'kakao' (0) | 2022.08.24 |