OAuth 개념

NHN FORWARD 22 로그인에 사용하는 OAuth: 과거, 현재 그리고 미래 강의를 보고 작성한 내용입니다

https://www.youtube.com/watch?v=DQFv0AxTEgM 

 

 

 

인증 - Authentication

---

경찰관에게 신분증으로 나의 신분을 증명하는 것 같은

인터넷에서 사용자의 신원을 확인하는 행위를 인증이라고 한다.

 

---

 

 

 

인가 - Authentication

---

내 자동차 키를 줌으로써 대리운전 기사가 내 소유의 자동차를 운전할 수 있는 것 처럼

사용권한을 위임하는 것을 인가라고 한다.

---

 

 

 

 

 

OAuth란?

---

프로토콜의 일종으로써

SNS 로그인에 주로 적용이 많이 된다.

OAuth 2.0을 알아보기에 앞서 OAuth 1.0에 대해 먼저 알아보도록 하자

 

---

 

 

 

 

 

OAuth 1.0

---

Resource Owner: 사용자 

 

OAuth Client: Resource Owner의 리소스에 접근해서 활용하려고 하는 어플리케이션

 

OAuth Server: Resource Owner의 신분을 확인해서 인증하고 

Resource Owner와 상호작용함으로써 OAuth Client에게 인가하는 역할

---

 

 

 

 

 

OAuth 1.0의 흐름

---

1. OAuth Client가 Resource Owner에게 인가를 받고 OAuth Server에게 인가 요청

2. OAuth Server가 인증 및 인가를 위해  OAuth Client -> Resource Owner에게 redirect 요청

3. Resource Owner가 ID, PW 입력

4. OAuth Server가 인증/인가를 완료하면 검증 값(아마 code?)을 Resource Owner에게 전달

5. Resource Owner가 검증 값을 OAuth Client에게 전달

6. OAuth Client가 검증 값을 요청으로 보내 OAuth Server로 부터 인가 토큰을 발급 받는다

7. OAuth Client가 토큰을 통해 OAuth Server로부터 Resource Owner의 사진을 받는다

 

---

 

 

 

 

OAuth 1.0의 문제점

---

1. Scope 개념이 없다

2. Client 구현 복잡함

3. 역할이 정확하게 나누어져 있지 않다

4. 토큰 유효기간 문제

5. 제한적인 사용 환경

 

---

 

 

 

 

 

 

 

OAuth 1.0에서 엿보는 웹 환경

---

인터넷 초창기

주로 간단한 정적 리소스를 보는데 사용되지 않았을까 추측한다고한다

 

---

 

 

 

 

 

 

 

OAuth 2.0 인가 프레임워크

---

OAuth 2.0에서는 OAuth 1.0의 단점을 고쳤다

1. Scope 기능 추가

해당 토큰에 대해서 얼만큼의 접근 범위가 있는지 나타냈다

 

 

 

2. Client 복잡성 간소화

 

Bearer Token과 TLS를 통해 Client 복잡성을 간소화했다

해당 토큰을 소유하는 것 만으로도

토큰에 대한 사용 권한이 있음을 인증해준다

TLS는 HTTPS를 강제한다.

 

 

 

3. 역할 분리

기존의 OAuth 1.0 Server의 보호된 리소스 관리는

Resource Owner 인증, 인가 토큰 발급과는 성격이 조금 달랐는데

이를 OAuth2.0에서 Authz Server와 Resource Server로 역할을 분리함으로써

더 멋진 아키텍처를 가져갈 수 있게 됐다

 

 

 

 

 

 

 

4. 토큰 탈취 문제 개선

 

토큰이 탈취당했을때 긴 기간동안 어뷰징을 할 수 있었는데,

OAuth2.0은 이 문제를 해결하기 위해 Refresh Token을 새로 만들었다

리소스 접근을 할때는 Access Token을 사용한다(유효기간이 굉장히 짧다)

서버 to 서버 통신에서 발급받은 refresh token을 사용한다면 새로운 access token을 발급받아

api와 리소스에 전달할 수 있다

이 방식을 사용하면 access token을 탈취당하더라도

access token의 짧은 유효기간동안 어뷰징할 수 있다는 장점이 있다.

 

 

 

 

5. 제한적인 사용 환경 개선

OAuth 1.0의 302 redirect는 웹 브라우저에서 작동하기 최적화되어있고

다른 환경에서는 사용하기 어려운 프로토콜이다

Grant는 OAuth2.0에서 여러가지 사용환경에 대한 플로우를 나타내는 인증방식이다

 

---

 

 

 

 

 

OAuth2.0의 Grant

---

---

 

 

 

 

OAuth 2.0에서 엿보는 웹 환경

---

javascript와 스마트기기가 추가되었다

---

 

 

 

 

oauth2.1

---

OAuth2.0이 인기를 끌며

금융권, 의료계, 증권시장 등의 보안적으로 더 민감한 클라이언트들도 수요가 늘어남

그러나 OAuth1.0 -> OAuth2.0 에서 클라이언트의 복잡성을 최소화하고자

보안을 조금 포기했다

OAuth2.1은 보안을 좀더 보완하도록한다

 

---

 

 

 

Open ID Connect

---

OAuth2.0기반으로 확장형식으로 인증기능을 추가한 스펙

 

 

 

 

 

직접적으로 ID Token을 파싱하고 안의 서명값을 검증함으로써

API Call을하지 않고도 사용자의 정보를 가져올 수 있다

OPEN ID가 자주쓰이는 이유

 

---

 

 

 

OPEN ID CONNECT에서 엿보는 웹 환경

---

여러 사용자의 트래픽을 감당하기 위해,

통신 부하를 줄이기위해 OPEN ID CONENCT가 생겼다

---

 

 

 

 

인증/인가의 미래, GNAP*

---

GNAP는

OAUTH2.0 기반 프로토콜 X

하위호완성 목적 X

---

 

 

 

OAuth2.0과 GNAP*의 차이

---

Grant라는 개념이 Interaction이라는 개념으로 확장

---

 

 

 

 

 

미래의 웹 개발은 GNAP이 주도할 것이라고 예측하신다

 

 

 

 

 

 

요약