내 비밀번호를 직접 넘기지 않고도 다른 앱이 내 데이터에 접근할 수 있도록 사용자의 접근 권한을 위임하는 표준 프로토콜
예를들어 아래 이미지와 같이

우리가 로그인할 때 직접 ID/PW를 입력하지 않고 구글, Apple 등이 사용자의 인증을 처리해주는 것도 OAuth을 기반한 로그인 방식이라고 할 수 있습니다.
OAuth를 사용하기 이전에는 타사 애플리케이션에 계정 접근 권한을 부여할 때
사용자가 ID/PW를 직접 제공해야 했습니다.
하지만 ID/PW를 직접 제공하는 방식은 타사 앱이 사용자의 ID/PW를 저장하거나 중간에 탈취 당할 수도 있고 해당 ID/PW로 사용자의 모든 권한에 접근 가능하는 등 보안적인 위험이 있었습니다.
이 문제를 해결하기 위해 구글, 야후, 아마존 등읜 각자 인증 시스템을 개발했습니다.
하지만 각 서비스마다 인증방식이 달라 개발하기에 어려움이 있었고, 보안 유지도 어려웠습니다.
때문에 2007년 여러 회사들이 모여서 OAuth라는 표준 프로토콜을 만들었습니다.
현재는 2012년에 발표된 OAuth 2.0 표준을 주로 사용합니다.
리소스 소유자
애플리케이션이 액세스하려는 계정을 소유한 최종 사용자
위의 예시에서는 로그인 하려는 사용자가 리소스 소유자입니다.
리소스 서버
사용자를 대신하여 보호된 리소스를 저장하는 서버.
클라이언트로부터 받은 OAuth 토큰을 수락하고 유효성을 검사한 후 리소스 소유자가 공개에 동의한 사용자 데이터를 제공합니다.
고객
액세스를 요청하는 애플리케이션, 웹사이트 API 또는 디바이스를 말합니다.
클라이언트 ID를 제시하여 Authorization Server에 권한 부여를 요청합니다.
권한 부여 서버
Client가 Resource Server의 서비스를 사용할 수 있게 인증하고, 토큰을 발행해주는 서버
OAuth 프롬포트를 표시하고 사용자가 애플리케이션의 요청을 승인 또는 거부하는 서버입니다.
또한 사용자가 애플리케이션을 승인한 후 액세스 토큰을 부여하는 역할도 합니다.
액세스 토큰은 API에 인증된 요청을 보낼 때 사용되는 문자열입니다.
사용자가 타사 애플리케이션의 계정 접근을 승인 했음을 나타내고
토큰에는 해당 액세스 기간, 범위, 서버에 필요한 기타 정보가 포함되어 있습니다.


사용자가 Google로 로그인을 클릭하여 Client에 로그인을 요청한다.
CLient는 Authorization Server에 로그인을 요청하는데 이때 Authorization Server가 제공하는 URL에 client_id, rediret_url, scope 등의 매개변수를 쿼리 스트링으로 포함하여 보낸다.
https://인증서버URL/auth?client_id=1234
&redirect_url=client콜백URL
&scope=create+delete

Google의 로그인 화면으로 ReDirection 된다.
로그인 성공시 Authorization Code를 클라이언트에 전달한다.
클라이언트는 받은 Authorization Code를 사용해 Access Token을 받아온다.
Client는 발급받은 Access Token을 저장하고 이후 Resource Server에 접근할 때는 Access Token으로 접근한다.
해당 토큰으로 Google에서 사용자의 이메일 등 리소스를 받아와서 로그인 처리한다.
https://www.oauth.com/oauth2-servers/background/
https://hudi.blog/oauth-2.0/#OAuth-%EB%93%B1%EC%9E%A5-%EB%B0%B0%EA%B2%BD
https://www.ibm.com/kr-ko/think/topics/oauth
추가로 공부하고 싶은 내용