-
OAuth란?프로그래밍 기초 공부 2022. 11. 10. 22:26
[ OAuth ]
- Open Authorization의 약자
- 인터넷 사용자들이 비밀번호를 제공하지 않고 다른 웹사이트 상의 자신들의 정보에 대해 웹사이트나 애플리케이션의 접근 권한을 부여할 수 있는 공통적인 수단으로서 사용되는, 접근 위임을 위한 개방형 표준
- 사용자들이 타사 애플리케이션이나 웹사이트의 계정에 관한 정보를 공유할 수 있게 허용
- 다른 서비스의 회원 정보를 안전하게 사용하기 위해서 사용
[ OAuth의 기원 ]
- OAuth가 사용되기 전에는 인증방식의 표준이 없었기 때문에 기존의 기본인증인 아이디와 비밀번호를 사용
- 보안상 취약한 구조일 가능성이 높음
- 기본 인증이 아닐 경우는 각 애플리케이션들이 각자의 개발한 회사의 방법대로 사용자를 확인
- ex) 구글의 AuthSub, AOL의 OpenAuth, 야후의 BBAuth, 아마존의 웹서비스 API 등
- OAuth는 이렇게 제각각인 인증방식을 표준화한 인증방식
- OAuth를 이용하면 이 인증을 공유하는 애플리케이션끼리는 별도의 인증이 필요없음
- 여러 애플리케이션을 통합하여 사용하는 것이 가능
[ OAuth1 과 OAuth2의 차이 ]
- OAuth는 총 고객, 고객이 이용하려는 애플리케이션, 고객 정보를 가지고 있는 애플리케이션 3개가 상호작용하는 형태
- 구현이 복잡함
- HMAC를 통한 암호화를 하는 번거로움
- 인증토큰이 만료가 되지 않아 토큰을 만료하려면 제공자 애플리케이션의 비밀번호를 바꿔야 함
- -> OAuth 2.0이 등장
- 기능의 단순화, 기능과 규모의 확장성 등을 지원하기 위해 만들어짐
- https를 통해 암호화를 하여 과정이 단순해짐
- 다양한 인증 방식이 제공
- api서버에서 인증서버와 리소스 서버가 분리됨
[ OAuth 요소 ]
OAuth 동작에 관여하는 요소는 크게 세 가지로 구분할 수 있음
- Resource Owner
- 서드파티 애플리케이션에 이미 개인정보를 저장하고 있으며 Client가 제공하는 서비스를 이용하려는 사용자
- Resource Server
- 사용자의 개인정보를 가지고있는 애플리케이션 서버
- Client는 Token을 이 서버로 넘겨 개인정보를 응답 받을 수 있음
- Authorization Server
- 권한을 부여해주는 서버
- 사용자는 이 서버로 ID, PW를 넘겨 Authorization Code를 발급 받을 수 있음
- Client는 이 서버로 Authorization Code을 넘겨 Token을 발급 받을 수 있음
- Client
- Resource Server 에서 제공하는 자원을 사용하는 애플리케이션
[ OAuth 동작방식 ]
- Resource Owner가 Client의 "카카오로 로그인하기" 등의 버튼을 클릭해 로그인을 요청
- Client는 OAuth 프로세스를 시작하기 위해 사용자의 브라우저를 Authorization Server로 보내야함
- Client는 이때 Authorization Server가 제공하는 Authorization URL에 매개변수를 쿼리 스트링으로 포함하여 보냄
- reponse_type : 반드시 code로 값을 설정
- client_id : 애플리케이션을 생성했을 때 발급받은 Client ID
- redirect_uri : 애플리케이션을 생성할 때 등록한 Redirect URI
- scope : Client가 부여받은 리소스 접근 권한
- Client는 이때 Authorization Server가 제공하는 Authorization URL에 매개변수를 쿼리 스트링으로 포함하여 보냄
- Client가 빌드한 Authorization URL로 Resource Owner를 이동시킴
- Resource Owner는 제공된 로그인 페이지에서 ID와 PW등을 입력하여 인증할 것
- 인증이 성공하면 Authorization Code를 발급해줌
- 인증이 성공되면, Authorization Server 는 제공된 Redirect URI로 사용자를 리디렉션시킴
- 이때, Redirect URI에 Authorization Code를 포함하여 사용자를 리디렉션시킴
- Client는 Authorization Server에 Authorization Code를 전달하고, Access Token을 응답
- Access Token은 유출되면 안됨
- 제 3자가 가로채지 못하도록 HTTPS 연결을 통해서만 사용될 수 있음
- Authorization Code와 Access Token 교환은 token 엔드포인트에서 HTTP 요청으로 이루어짐
- 이때 필수로 전달해야하는 매개변수가 있음
- grant_type : 항상 authorization_code 로 설정되어야 함
- code : 발급받은 Authorization Code
- redirect_uri : Redirect URI
- client_id : Client ID
- client_secret : RFC 표준상 필수는 아님, Client Secret이 발급된 경우 포함하여 요청해야함 Client ID에 대한 비밀키로서, 절대 노출시키면 안됨
- 이때 필수로 전달해야하는 매개변수가 있음
- Client는 발급받은 Resource Owner의 Access Token을 저장
- 위 과정이 성공적으로 마무리되면 Client는 Resource Owner에게 로그인이 성공하였음을 알림
- 이후 Resource Owner가 Resource Server의 리소스가 필요한 기능을 Client에 요청
- Client는 위 과정에서 발급받고 저장해둔 Resource Owner의 Access Token을 헤더에 담아 API 호출
- Access Token이 맞는지 검증하고 Client에 서비를 넘겨줌
- Client는 Resource Owner에게 자사의 서비스를 제공
[ 인증종류 ]
- Password Credentials Grant
- Client에 ID/PW를 저장해 놓고, ID/PW로 직접 accesstoken을 받아오는 방식
- Client를 믿을 수 없을 때에는 사용하기 위험
- APi 서비스의 공식 어플리케이션이나 믿을 수 있는 Client에 한해서 사용하는 것을 추천
- 로그인시에 API에 POST로 grant_type=credentails라고 넘김
- Client Credentails Grant
- 어플리케이션이 Confidentail Client일 때, ID와 Secret을 가지고 인증하는 방식
- 로그인시에 API에 POST로 grant_type=client_credentails라고 넘김
[ OAuth 2.0의 스코프 ]
- OAuth 2.0은 스코프라는 개념을 통해서 유저 리소스에 대한 클라이언트의 접근 범위를 제한할 수 있음
- 스코프는 여러개가 될 수 있으며, 대소문자를 구문하는 문자열을 공백으로 구분하여 표현
- 이때 문자열은 OAuth 2.0 인증 서버에 의해 정의
ex)
우리의 서비스가 사용자의 구글 연락처를 받아오고 싶다면
OAuth 2.0 스코프에 연락처 스코프 문자열을 포함하여 OAuth 2.0 제공자에게 전달
사용자는 스코프에 명시된 권한을 요청하는 화면을 만날 수 있을 것 있음
이 과정을 거쳐 발급된 액세스 토큰은 부여된 스코프에 해당하는 권한을 제한적으로 획득할 수 있음'프로그래밍 기초 공부' 카테고리의 다른 글
GraphQL이란? (1) 2022.11.14 CI / CD 란? (1) 2022.11.11 URL, URI란? (0) 2022.11.07 TCP, UDP란? (0) 2022.11.06 세션, 쿠키, 토큰이란? (0) 2022.11.04