OAuth

OAuth란?

자신이 소유한 리소스에 소프트웨어 애플리케이션이 접근할 수 있도록 허용해 줌으로써 
접근 권한을 위임해주는 개방형 표준 프로토콜

⇒ 위와 같이 간편하게 회원가입 및 로그인을 할 수 있는 애플리케이션 이때 사용되는 프로토콜이 OAuth!!

OAuth의 탄생배경

A사이트에서 B사이트의 리소스를 가져오기 위해서 B사이트의 ID와 Password를 직접 불러와서 사용

•

발생하는 문제

◦

사용자: A사이트에 B사이트의 ID와 Password를 넘겨주는 것에 대해 신뢰할 수 없다

◦

A 사이트: ID와 Password를 받았기 때문에 보안 문제가 생기는 경우 모든 책임을 져야한다

◦

B 사이트: A 사이트를 신뢰할 수 없다

⇒ 이러한 문제를 해결하기 위해 OAuth 탄생

OAuth 2.0은 1.0에서 알려진 보안 문제 등을 개선한 버전

비교	OAuth1.0	OAuth2.0
참여자 구분	- 이용자 - 소비자 - 서비스 제공자	- 자원 소유자 - 클라이언트 - 권한 서버 - 자원 서버
토큰	- 요청 토큰(Request Token) - 접근 토큰(Access Token)	- 접근 토큰(Access Token) - 재발급 토큰(Refresh Token)
유효기간	접근 토큰의 유효기간 없음	- 접근 토큰 유효기간 부여 - 만료 시 재발급 토큰 이용
클라이언트	웹 서비스	웹, 앱 등

OAuth의 구성요소

•

Resource Owner : 웹서비스를 이용하려는 유저, 자원(개인정보)를 소유하는 자, 사용자

•

Client : 자사 또는 개인이 만든 애플리케이션 서버

◦

클라이언트라는 이름은 resource server에게 필요한 자원을 요청하고 응답하는 관계여서

•

Authorization Server: 권한을 부여(인증에 사용할 아이템을 제공) 해주는 서버

◦

사용자는 이 서버로 ID, PW를 넘겨 Authorization Code를 발급 받을 수 있음

◦

Client는 이 서버로 Authorization Code를 넘겨 Token을 발급 받을 수 있음

•

Resource Server: 사용자의 개인정보를 가지고 있는 애플리케이션 회사 서버 (Google, Kakao 등)

◦

Client는 Token을 이 서버로 넘겨 개인정보를 응답 받음

•

Access Token: 자원에 대한 접근 권한을 Resource Owner가 인가하였음을 나타내는 자격증명

•

Refresh Token

◦

Client는 Authorization Server로 부터 access token(비교적 짧은 만료기간)과 refresh token(비교적 긴 만료기간)을 함께 부여 받음

◦

access token은 보안상 만료기간이 짧기 대문에 얼마 지나지 않아 만료되면 사용자는 로그인을 다시 시도해야함

⇒ refresh token이 있다면 access token이 만료될 때 refresh token을 통해 access token을 재발급 받아 재 로그인 할 필요 없게끔 한다.

▪

그냥 refresh token만 쓰면 되는거 아닌가?

→ refresh token은 권한 서버에서만 활용되며 리소스 서버에는 전송되지 않음

직접 사용자가 로그인하는 것이 아닌 소셜 미디어로 로그인할 경우
client(개인 서비스)는 Resource Owner(사용자)를 대신해 로그인 하는데
이때, 필요한 정보를 Resource Server에서 얻어 서로 비교해 유효성을 판단

⇒ client가 유저의 로그인 정보/ 자원(resource)을 Resource Server에 요청해 대신 로그인

이를 위해서 client가 가지는 단계

Resource Owner로부터 동의(허용)

Resource Server로부터 client 신원 확인

WHY

Resource Owner(유저) 입장

•

자신의 정보를 대신 사용하기 때문에 
client가 어떤 정보를 활용하는지, 어떤 기능을 사용하려는지 모름

•

개인정보를 마구잡이로 악용할 수도 있음

⇒ client는 Resource Owner의 동의를 구해야 함

Resource Server(Kakao) 입장

•

다른 사람의 일을 대신 해주는 사람이 정말 그 사람일지 궁금

•

Resource Owner의 일을 수행해주는 client가 정말 그 client일까?

⇒ Resource Server는 Resource Owner의 브라우저를 통해 client를 구분하는 값(code)를 전달

인증 종류

Authorization Code Grant (인가 코드 승인)

Implicit Grant (암묵적 승인)

Resource Owner Password Credentials Grant (리소스 소유자 암호 자격 승인)

Client Credentials Grant (클라이언트 자격 승인)

	Confidential Client	Public Client
3-legged	Authorization Code	Implicit
2-legged	Resource Owner Password Credentials	Client Credentials

3-legged, 2-legged

Authorization Code Grant (인가 코드 승인)

권한 부여 승인을 위해 자체 생성한 Authorization Code를 전달하는 방식으로 많이 쓰이고 기본이 되는 방식

간편 로그인 기능에서 사용되는 방식으로 클라이언트가 사용자를 대신하여 특정 자원에 접근을 요청할 때 사용되는 방식입니다. 보통 타사의 클라이언트에게 보호된 자원을 제공하기 위한 인증에 사용됩니다.

•

리소스 접근을 위해 인가 서버(Authorization Server)에서 받은 권한 코드로 리소스에 대한 액세스 토큰을 받는 방식

•

Refresh Token의 사용이 가능

•

다른 인증 절차에 비해 보안성이 높기에 주로 사용

Implicit Grant (암묵적 승인)

자격증명을 안전하게 저장하기 힘든 클라이언트(ex: JavaScript등의 스크립트 언어를 사용한 브라우저)에게 최적화된 방식

암시적 승인 방식에서는 권한 부여 승인 코드 없이 바로 Access Token이 발급 됩니다. Access Token이 바로 전달되므로 만료기간을 짧게 설정하여 누출의 위험을 줄일 필요가 있습니다.

•

권한 부여 코드 승인 타입(Authorization Code Grant)와 다르게 권한 코드 교환 단계가 없음

•

액세스 토큰을 즉시 반환받아 이를 인증에 이용하는 방식

Resource Owner Password Credentials Grant (리소스 소유자 암호 자격 승인)

간단하게, username, password로 Access Token을 받는 방식

클라이언트가 타사의 외부 프로그램일 경우에는 이 방식을 적용하면 안됩니다. 자신의 서비스에서 제공하는 어플리케이션일 경우에만 사용되는 인증 방식입니다. Refresh Token의 사용도 가능합니다.

•

Client가 암호를 사용하여 액세스 토큰에 대한 사용자의 자격 증명을 교환하는 방식

•

Resource Owner에서 ID, Password를 전달 받아 Resource Server에 인증하는 방식으로 신뢰할 수 있는 Client에 한해서만 사용하는 것 추천

Client Credentials Grant (클라이언트 자격 승인)

클라이언트의 자격증명만으로 Access Token을 획득하는 방식

OAuth2의 권한 부여 방식 중 가장 간단한 방식으로 클라이언트 자신이 관리하는 리소스 혹은 권한 서버에 해당 클라이언트를 위한 제한된 리소스 접근 권한이 설정되어 있는 경우 사용됩니다.

•

Client가 컨텍스트 외부에서 엑세스 토큰을 얻어 특정 리소스에 접근을 요청할 때 사용하는 방식

MDS인텔리전스 블로그 : 네이버 블로그

https://blog.naver.com/mds_datasecurity/222182943542

OAuth 서비스 등록

서비스를 등록하면 받게되는 필수 요소

•

Client ID

◦

어플리케이션(서비스)을 식별하는 식별자ID를 의미한다.

◦

다양한 서비스가 존재하는데, Resource Server 입장에서 어떤 서비스에게 제공할 것 인지 구분하는 ID를 의미한다.

•

Client Secret

◦

Client ID에 대한 비밀번호로 외부에 노출되면 안된다.

◦

ID의 PASSWORD라고 생각하면 된다.

•

Authorized redirect URIs

◦

Resource Server만 갖는 정보로, client에 권한을 부여하는 과정에서 나중에 Authorized code를 전달하는 통로다.

◦

나중에 client <-> Resource Server 유효성 검사에서 이 redirect URIs도 체크되며 해당주소가 아닐 경우 Resource Server는 해당 client가 아니라고 판단한다.

◦

즉, 예를들어 네이버 서버가 사용자의 개인정보를 콜백할 주소를 적는 곳이다.

Resource owner 승인과정

[WEB] 📚 OAuth 2.0 개념 정리 (그림으로 이해하기 쉽게)

웹 서핑을 하다 보면 Google과 Facebook 등의 외부 소셜 계정을 기반으로 간편히 회원가입 및 로그인할 수 있는 웹 어플리케이션을 쉽게 찾아볼 수 있다. 클릭 한 번으로 간편하게 로그인할 수 있을 뿐만 아니라, 연동되는 외부 웹 어플리케이션에서 Facebook 및 Twitter 등이 제공하는 기능을 간편하게 사용 할 수 있다는 장점이 있다.

https://inpa.tistory.com/entry/WEB-%F0%9F%93%9A-OAuth-20-%EA%B0%9C%EB%85%90-%F0%9F%92%AF-%EC%A0%95%EB%A6%AC

[WEB] 📚 OAuth 2.0 개념 정리 (그림으로 이해하기 쉽게)

https://inpa.tistory.com/entry/WEB-%F0%9F%93%9A-OAuth-20-%EA%B0%9C%EB%85%90-%F0%9F%92%AF-%EC%A0%95%EB%A6%AC

[OAuth] OAuth2.0란?

자신이 소유한 리소스에 소프트웨어 애플리케이션이 접근할 수 있도록 허용해 줌으로써 접근 권한을 위임해주는 개방형 표준 프로토콜 OAuth이 등장하기 전에 A 사이트에서 B 사이트의 리소스를 가져오기 위해서는 다른 사이트의 ID와 Password를 직접 입력 받아 저장하여 필요할 때마다 불러와서 사용을 해야했다. 위와 같은 방식을 사용하게되면 다음과 같은 문제가 발생한다.

https://doqtqu.tistory.com/295

IT위키

자신이 소유한 리소스에 소프트웨어 애플리케이션이 접근할 수 있도록 허용해 줌으로써 접근 권한을 위임해주는 개방형 표준 프로토콜 애플리케이션이 리소스 소유자에게 리소스에 대한 접근 권한을 허용하고, 요청 결과로 전달받은 토큰을 이용해 애플리케이션이 해당 리소스에 접근하는 프로토콜 여러 웹 서비스를 연계하여 사용토록 하기 위해 OpenID 이용 API 접근 권한 관리를 위해 구글의 AuthSub,

https://itwiki.kr/w/OAuth

OAuth 란 무엇일까

아래와 같은 로그인 창을 보셨을 것입니다. 별도의 회원가입 없이 로그인을 제공하는 플랫폼의 아이디만 있으면 서비스를 이용 할 수 있습니다. 외부 서비스에서도 인증을 가능하게 하고 그 서비스의 API를 이용하게 해주는 것, 이것을 바로 OAuth라고 합니다. 출처: naver developer OAuth 2.0은 다양한 플랫폼 환경에서 권한 부여를 위한 산업 표준 프로토콜입니다.

https://showerbugs.github.io/2017-11-16/OAuth-%EB%9E%80-%EB%AC%B4%EC%97%87%EC%9D%BC%EA%B9%8C