OAuth2(Open Authorization)

📖OAuth

OAuth = Open + Authorization (개방형 인가)

OAuth2.0 인가 프레임워크는 애플리케이션이 사용자 대신하여 사용자의 자원에 대한 제한된 엑세스를 얻기 위해 승인 상호 작용을 함으로써 애플리케이션이 자체적으로 엑세스 권한을 얻도록 한다. 

사용자가 속한 사이트의 보호된 자원에 대하여 어플리케이션의 접근을 허용하도록 승인하는 것이다. (인증 보다는 인가에 초점)

 

이 방법을 사용하는 이유?

 

1. 아이디와 패스워드로 로그인 할 필요가 없다. (사용자 인증 및 동의)

2. 페이스북의 서비스를 범위에 따라 제한할 수 있다. (scope)

3. 클라이언트 어플리케이션의 신뢰여부를 판단할 필요가 없다.

• 사용자가 클라이언트에게 ID,PW를 넘기는게 아니라 어플리케이션이 사용자 정보를 얻을 수 있도록 사용자가 승인해주는 것

 

🙋🏼‍♀️OAuth 2.0 Roles

다음 네 가지 종류의 역활을 담당하는 주체들에 의해 이루어지는 권한부여 체계

 

1.  Resource Owner(자원 소유자)

보호된 자원에 대한 접근 권한을 부여할 수 있는 주체, 사용자로서 계정의 일부에 대한 접근 권한을 부여하는 사람
사용자를 대신하여 작동하려는 모든 클라이언트는 먼저 사용자의 (허가 + 동의)를 받아야 한다.

사용자의 허가(즉 인증)



사용자의 동의

2. Resource Server(보호자원서버)

타사 어플리케이션에서 접근하는 사용자의 자원이 포함된 서버를 의미한다.
액세스 토큰을 수락 및 검증할 수 있어야 하며 권한 체계에 따라 요청을 승인할 수 있어야 한다.

3. Authorization Server(인가서버)

클라이언트가 사용자 계정에 대한 동의 및 접근을 요청할 때 상호 작용하는 서버로서 클라이언트의 권한 부여 요청을 승인하거나 거부하는 서버 사용자가 클라이언트에게 권한 부여 요청을 승인한 후 access token을 클라이언트에게 부여하는 역활

4. Client(클라이언트)

사용자를 대신하여 권한을 부여받아 사용자의 리소스에 접근하려는 어플리케이션
사용자를 권한 부여 서버로 안내하거나 사용자의 상호 작용 없이 권한 부여 서버로부터 직접 권한을 얻을 수 있다.

여기서 velog예로 너무 잘 설명해주셔서 가져왔다.

[OAuth + Spring Boot + JWT] 1. OAuth란? 프론트엔드와 백엔드의 역할

github 사용자인지 인증하는 과정은 github가 담당한다. OAuth는 이렇게 인증도 제공하지만, 주요 목적은 인증된 사용자에게 사용자의 이름이나, 이메일을 가져온다든지 하는 권한을 제공해주는 것이다.

 

👻권한 부여 유형

• 권한부여란 클라이언트가 사용자를 대신해서 사용자의 승인하에 인가서버로부터 권한을 부여받는 것을 의미한다.

1) Authorization Code Grant
Implicit Grant (Deprecated)
Resource Owner Password Credentials Grant (Deprecated)

2) Client Credentials Grant
3) Refresh Token Grant
4) PKCE-enhanced Authorization Code Grant

매개 변수 용어

1. client_id

클라이언트가 인가서버 등록할 때 생성되는 고유한 키(ID)

2. client_secret

인가서버에 등록된 특정 클라이언트의 client_id 에 대한 생성된 비밀 값

3. response_type

애플리케이션이 권한 부여 코드 흐름을 시작하고 있음을 인증 서버에 알려준다. (Authorization Code Grant방식은 code)

• code, token, id_token이 있으며 token, id_token 은 인가서버가 지원을 해줘야 가능하다. (아니면 에러 뱉음 ㅜ.ㅜ)

4. grant_type

권한 부여 타입 지정 - authorization_code, password, client_credentials, refresh_token

5. redirect_uri

사용자가 응용 프로그램을 성공적으로 승인하면 권한 부여 서버가 사용자를 다시 응용 프로그램으로 리디렉션 한다.

• redirect_uri 가 초기 권한 부여 요청에 포함된 경우 서비스는 토큰 요청에서도 이를 요구해야 한다.  그렇지 않으면 서비스는 요청을 거부

6. scope

어플리케이션이 사용자 데이터에 접근하는 것을 제한하기 위해 사용된다.(즉 토큰이 있는 상태로 인가서버 접근할 때)

- email profile read write ...

7. state

응용 프로그램은 임의의 문자열을 생성하고 요청에 포함하고 사용자가 앱을 승인한 후 서버로부터 동일한 값이 반환되는지 확인해야 한다.

- CSRF 공격을 방지하는 데 사용된다.

 

Authorization Code Grant 방식을 그러면 알아보자!

keycloak을 통해서 테스트 해봤다.

 

해당 URL로 요청을하면 사용자의 인증과 동의를 구하게 된다.

사용자의 허락이 완료되면 session_state, code을 받을 수 있다.

http://localhost:8081/?session_state=f02f3cc4-d01a-43b5-b6b5-f582e391fa49&code=162b0940-a760-40dc-9f55-d9263ece27ca.f02f3cc4-d01a-43b5-b6b5-f582e391fa49.3393fead-39e7-4819-a6a2-c13e734a6e4f

이 code 값을 가지고 매개변수에 넣어주면

AccessToken이랑 Refresh_token을 발급받았고 이AccessToken을 통해서 인가서버에 자원을 요청할 수 있다.

User정보를 얻을 수 있다.!!

 

OpenID Connect 1.0 에 대해서 조금 알아보자

OpenID Connect 1.0은 OAuth2.0 프로토콜 위에 구축된 ID계층으로 OAuth2.0을 확장하여 인증 방식을 표준화 한 OAuth2.0 기반의 인증 프로토콜

scope 지정시 'openid' 를 포함하면 OpenID Connect 사용이 가능하다. (인가서버에서 지원할 경우) 인증에 대한 정보는 ID토큰이라고 하는 JWT으로 반환된다.

 

OAuth2.0 기반은 Authorization(인가)이고 OpenID Connect 1.0은 Authentication(인증)인걸 기억하자.