Rest API (웹 API)
https://www.youtube.com/watch?v=RP_f5dMoHFc
강의 보기!!
OAuth 2.0
Why
- 현재 소셜 인증 등으로 가장 널리 사용되는 방법
- 상대적으로 간편하고 안전
학습 목표
- 여러가지 인증 방법에 대해 이해한다
인증과 권한부여
- 인증(authentication): 주장한 사실(내가 나임)이 맞는지 확인
- 권한 부여(authorization): 특정 리소스에서 오퍼레이션을 수행할 때 해당하는 권한이 있는지, 없는지 확인 후 권한을 수행할 수 있게 하는 것
여러 인증 방법
아이디, 패스워드 방식
- 패스워드: 해당하는 아이디의 주인인지 아닌지 확인하기 위해서 패스워드 사용
- 토큰인증: 무작위로 흉내내기 어려운 긴 토큰을 가지고 사용자를 확인
- Access Token, Refresh Token을 함께 사용:
- JWT을 사용한 인증:
- LDAP/AD: 기업에서 많이 사용. (e.g. Outlook 인증, 윈도우즈 로그인)
- 기타
OAuth 2.0
- 기업들이 만든 인증 표준
- 2006년 v1이 나온 이후 여러가지 개선을 거쳐 현재 2.0
- https://oauth.net/2/
- 1.0은 트위터가 만들었음. 2.0은 여러 회사가 합작
- 2.0은 하위호환성이 없음
OAuth2 장점 및 필요성
- 인증과 권한 부여를 동시에 함
- 일반 사용자의 정보유출을 막으면서도 서드 파티에게 필요한 정보를 제공 가능
- 세밀한 scoope 제어 가능
- 현재 사실상 업계 표준
용어 정의
- Resource Owner: 일반적인 사용자
- Client: 서비스 제공자
- Authorization Server: 인증을 담당하는 서버(e.g. 깃헙 인증 서버)
- Resource Server: 리소스를 클라이언트에게 제공해주는 서버 (e.g.깃헙 데이터 서버)
- User-agent: 웹브라우저
OAuth2의 동작원리
- Client가 Resource Owner 한테 Resource Server에 인증이 가능한지 물어본다. 허락을 받으면 Authorization Server가 Resource Server의 접근 권한을 Client에게 열어준다
- Authorization Server URL을 Client에서 User-Agent로 보냄
- Authorization Server 에 가서 유저가 auth를 함 (스코프가 url에 포함되어 있음)
- Authorization Server가 Authorization Code를 보냄 (HTTP 리다이렉션으로 보냄)
- User agent가 Authorization Code를 Client에게 보냄
- Client 에서 Authorization Code를 받아서 Authorization Server로 감
- 마지막으로 Access Token이 나옴! (Optional Refresh Token)
Authorization Code Grant
- HTTP 리다이렉션을 통해 리소스 오너가 직접 코드를 획득하는 방식
- 가장 대표적으로 사용되는 방법
다양한 OAuth2의 인증 방식
- Authorization Code
- PKCE
OAuth2 구현 방법
- 클라이언트 아이디와 시크릿키를 깃헙이 만들어줌. 잘 저장해서 재사용. 콜백 URL은 프론트가 만들고 깃허브에 등록해준다.
- 유저가 로그인 버튼을 누른다.
- 버튼을 누르면 clientid, redirecturl, scope가 저장된 Url로 이동한다. (깃헙에 요청)
- 유저가 깃허브에서 서비스에 로그인한다 (권한 허용) 302 리다이렉션으로
- 유저가 리다이렉션 url로 이동한다. 여기에 auth code도 쿼리로 같이 딸려 옴
이 'code'라는 쿼리를 가지고 서버에 보내줘야함 - 이제 다시 깃허브에 clientid, secret, authorization code 를 보내줘야함
- accesskey를 획득하면 깃허브에 다시 리소스 요청. 리소스 요청 가능
https://docs.github.com/en/apps/oauth-apps/building-oauth-apps/authorizing-oauth-apps
