Notice
Recent Posts
Recent Comments
Link
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | ||||||
2 | 3 | 4 | 5 | 6 | 7 | 8 |
9 | 10 | 11 | 12 | 13 | 14 | 15 |
16 | 17 | 18 | 19 | 20 | 21 | 22 |
23 | 24 | 25 | 26 | 27 | 28 |
Tags
- 빈 조회 2개 이상
- jwt
- 프로그래머스
- @FeignClient
- JavaScript
- 구글 OAuth login
- 전략패턴 #StrategyPattern #디자인패턴
- 취업리부트코스
- 1주일회고
- KPT회고
- DesignPattern
- 빈 충돌
- TiL
- jwttoken
- 개발자부트캠프추천
- Python
- 디자인 패턴
- 개발자 취업
- spring batch 5.0
- 커스텀 헤더
- 인프콘 2024
- 코딩테스트 준비
- 디자인패턴
- infcon 2024
- 파이썬
- 99클럽
- 단기개발자코스
- Spring multimodule
- 항해99
- 프로그래머스 이중우선순위큐
Archives
- Today
- Total
m1ndy5's coding blog
ABOUT OAuth 2.0 본문
OAuth 2.0(Open Authorization 2.0)은 인증을 위한 개방형 표준 프로토콜
이 프로토콜에서는 Third-Party 프로그램에게 리소스 소유자를 대신하여 리소스 서버에서 제공하는 자원에 대한 접근 권한을 위임하는 방식을 제공
대표적으로 구글, 페이스북, 카카오, 네이버 등에서 제공하고 있다.
권한 부여 방식
Authorization Code Grant 권한 부여 승인 코드 방식
권한 부여 승인을 위해 자체 생성한 Authorization Code를 전달하는 방식으로 많이 쓰이고 기본이 되는 방식
간편 로그인 기능에서 사용되는 방식으로 클라이언트가 사용자를 대신하여 특정 자원에 접근을 요청할 때 사용되는 방식
보통 타사의 클라이언트에게 보호된 자원을 제공하기 위한 인증에 사용된다. Refresh Token의 사용이 가능한 방식
예를 들어 내 프로젝트에 구글 간편 로그인을 사용한다고 가정해보자.
- Resource Owner : 구글 간편 로그인을 사용하는 유저 (구글에 개인정보를 제공한 사용자)
- Client : 내 프로젝트 (리소스 서버에 해당 Resource Owner의 리소스를 요청하는 애플리케이션)
- Authorization Server : 구글 인가 서버 (Resource Owner의 인증을 받아 엑세스 토큰을 발급하는 서버, Authorization Server와 Resource Server는 같은 서버일 수도, 별도의 서버일 수도 있음)
- Resource Server : 구글 리소스 서버 (Resource Owner의 리소스를 가지고 있는 서버)
가 되는 것이다.흐름
- 사용자가 서비스 서버에게 구글 소셜로그인을 요청한다.
- 서비스 서버가 구글 인가 서버에 로그인을 요청한다. -> 권한 부여 승인 코드 요청
- 구글 로그인으로 리다이렉트된다. -> 구글 로그인 팝업 출력
- 사용자가 구글 로그인을 한다.
- 구글 인가 서버에서 서비스 서버에게 로그인이 완료됐다고 전달된다. -> 권한 부여 승인 코드 전달
- 서비스의 서버가 구글 인가 서버에게 Access Token을 달라고 요청한다. -> 권한 부여 승인 코드를 가지고 요청
- 구글 인가 서버가 서비스 서버에 Access Token을 전달한다.
- 서비스 서버는 Access Token을 가지고 구글 리소스 서버에 자원을 달라고 요청한다. (ex. 사용자의 이름, 나이 등등)
- 구글 리소스 서버는 해당 Access Token이 유효하면 요청 자원을 전달하게 된다.
- 요청 자원 전달이 완료 되면 서비스 서버에서도 완료~~!!의 응답을 사용자에게 준다.
Implicit Grant 암묵적 승인 방식
자격증명을 안전하게 저장하기 힘든 클라이언트(ex. JavaScript등의 스크립트 언어를 사용한 브라우저)에게 최적화된 방식
암묵적 승인 방식에서는 권한 부여 승인 코드 없이 바로 Access Token이 발급 -> Access Token의 만료기간을 짧게 설정해 누출의 위험을 줄일 필요가 있음
Refresh Token 사용이 불가능함, Access Token을 획득하기 위한 절차가 간소화되어 응답성과 효율성은 높아지지만 Access Token이 URL로 전달됨
Resource Owner Password Credentials Grant 자원 소유자 자격증명 승인 방식
username, password로 Access Token을 받는 방식
클라이언트가 타사의 외부 프로그램일 경우에는 방식 적용하면 안됨
자신의 서비스에서 제공하는 애플리케이션일 경우만 사용되는 인증 방식. Refresh Token의 사용도 가능
Client Credentials Grant 클라이언트 자격증명 승인 방식
클라이언트의 자격증명만으로 Access Token을 획득하는 방식
클라이언트 자신이 관리하는 리소스 혹은 인증 서버에 제한된 리소스 접근 권한이 설정되어 있는 경우 사용
이 방식은 자격증명을 안전하게 보관할 수 있는 클라이언트에서만 사용되어야 하며, Refresh Token은 사용할 수 x
'클라우드 with AWS > Security' 카테고리의 다른 글
PKI(Public Key Infrastructure), ACM(AWS Certificate Manage) (0) | 2023.03.15 |
---|---|
Amazon Inspector, Aws Systems Manager, 암호화 (1) | 2023.03.13 |
시스템 강화 보안 (0) | 2023.03.12 |
ABOUT Firewall, AAA, DMZ (0) | 2023.03.10 |
ABOUT SECURITY (0) | 2023.03.10 |