일반적으로 사용되는 몇 가지 웹 보안 인증 방법을 소개합니다.

이 글에서는 일반적으로 사용되는 웹 보안 인증 방법 5가지를 소개합니다. 이 방법은 모든 사람에게 도움이 될 수 있습니다.

1. Http 기본 인증

이 방법은 API에 접속할 때 간단히 사용자 이름과 비밀번호를 가져오는 것입니다. 점점 더 적게 사용되며 이제 더 안전하고 기밀이 유지되는 인증 방법이 일부 오래된 플랫폼에서 여전히 사용될 수 있습니다.

아래 그림과 같이 사용자 이름과 비밀번호를 입력하는 상자가 나타납니다. 이는 Tomcat과 함께 제공되는 HTTPBasic 인증입니다.

이것은 애플리케이션에 액세스하기 위한 자격 증명입니다. xxxXXX 문자열은 암호 텍스트임을 나타내기 위해 작성한 것입니다. 이것은 사용자 이름과 비밀번호를 Base64로 암호화한 후에 얻은 것입니다. 이제 여러분도 같은 생각을 하시나요? 훔치기가 너무 쉽기 때문에 현재 새 응용 프로그램에서는 이 방법을 거의 사용하지 않습니다. 비록 간단하지만 보안 수준이 너무 낮습니다.

2. OAuth2

저의 이전 블로그에서는 OAuth2를 소개하고 Azure AD를 사용하여 OAuth2 인증을 구현했습니다. 여기서는 모든 사람이 요약하고 검토할 수 있도록 해당 블로그의 내용 중 일부를 추출하겠습니다.

https://blog.csdn.net/aHardDreamer/article/details/88650939

OAuth는 공개 인증(Open Authorization)을 의미합니다. 이는 사용자가 제3자에게 사용자 이름과 비밀번호를 제공하지 않고도 제3자 애플리케이션이 웹사이트에 저장된 사용자의 개인 리소스에 액세스할 수 있도록 하는 개방형 표준입니다. 예를 들어, 우리는 QQ/WeChat/Weibo 등을 통해 제3자 플랫폼에 로그인하는 데 익숙합니다. OAuth 1.0 버전이 출시된 후 많은 보안 허점이 있었기 때문에 클라이언트 개발자를 위한 단순성에 중점을 둔 OAuth 2.0에서는 OAuth 1.0이 완전히 폐지되거나 리소스 소유자와 HTTP 서비스 제공자 간의 승인된 계약을 통해 상호 작용이 이루어집니다. 사용자를 대신하여 또는 타사 애플리케이션이 사용자를 대신하여 액세스할 수 있도록 허용합니다. 읽기가 다소 복잡하지만 원리는 실제로 매우 간단합니다. 아래 설명을 참조하세요.

1. 먼저 OAuth2 인증 및 승인 프로세스에서 다음 세 가지 역할을 이해해야 합니다.

1. 서비스 공급자: 이름에서 알 수 있듯이 보호된 서비스와 리소스를 제공하며 사용자는 여기에 많은 것을 저장합니다.

2. 사용자: 서비스 제공업체에 물건(사진, 정보 등)을 저장한 사람입니다.

3. 클라이언트: 서비스 제공자의 리소스에 액세스하려면 서비스 제공자에 등록해야 합니다. 그렇지 않으면 서비스 제공자가 이를 사용하지 않습니다.

2. OAuth2 인증 및 승인 프로세스:

1) 사용자가 서비스 제공자에 저장된 리소스를 조작하려고 합니다.

2) 사용자가 클라이언트에 로그인하고 클라이언트가 서비스 제공자에게 임시 토큰을 요청합니다.

3) 서비스 제공자는 클라이언트의 신원을 확인한 후 임시 토큰을 제공합니다.

4) 클라이언트는 임시 토큰을 얻은 후 사용자를 서비스 제공자의 인증 페이지로 안내하고 사용자 인증을 요청합니다. (이 과정에서 임시 토큰과 클라이언트의 콜백 링크/인터페이스가 서비스 제공자에게 전송됩니다.---분명히 서비스 제공자는 사용자 인증 및 승인 후 이 인터페이스를 호출하기 위해 다시 돌아올 것입니다.)

5) 사용자는 user 비밀번호로 로그인하면 클라이언트는 서비스 제공업체의 리소스에 액세스할 수 있는 권한을 부여받을 수 있습니다.

6) 인증에 성공한 후 서비스 제공업체는 사용자를 클라이언트의 웹 페이지로 안내합니다(콜백 링크/인터페이스 호출). 4)

7) 클라이언트는 임시 토큰을 기반으로 서비스 제공자로부터 공식 액세스 토큰을 얻습니다.

8) 서비스 제공자는 임시 토큰 및 사용자 인증을 기반으로 클라이언트 액세스 토큰을 부여합니다. 9) 클라이언트는 액세스 토큰을 사용하여 서비스 공급자에 저장된 사용자의 보호 리소스에 액세스합니다.

3. 액세스 토큰(Grant Type)을 얻는 방법에는 네 가지가 있으며 각 방법에는 적용 가능한 애플리케이션 시나리오가 있습니다.

1. 인증 코드(인증 코드 모드)

일반 서버 측 애플리케이션과 함께 사용됩니다. .

1) 사용자가 클라이언트에 접속하고, 후자는 사용자가 인증을 승인했다고 가정하면, 인증 서버는 클라이언트가 미리 지정한 "리디렉션 URI"(리디렉션 URI)로 사용자를 리디렉션합니다. , 인증 코드를 첨부합니다.

2) 클라이언트는 인증 코드를 수신하고 이전 "리디렉션 URI"를 첨부한 후 인증 서버에서 토큰을 신청합니다: GET /oauth/token?response_type=code&client_id=test&redirect_uri=페이지 링크 리디렉션. 요청은 일반적으로 10분 동안 유효한 코드 승인 코드를 성공적으로 반환합니다.

3) 인증 서버는 인증 코드와 리디렉션 URI가 올바른지 확인한 후 액세스 토큰과 새로 고침 토큰을 클라이언트로 보냅니다. POST /oauth/token?response_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA&redirect_uri=페이지 링크 리디렉션. 요청은 액세스 토큰과 새로 고침 토큰을 성공적으로 반환합니다.

(무료 학습 동영상 공유: php 동영상 튜토리얼)

2. 암시적(간소화 모드)

모바일 애플리케이션 또는 웹 앱과 함께 사용하세요.

액세스 토큰은 인증 서버에서 직접 반환됩니다(프런트 엔드 채널만 해당)

새로 고침 토큰은 지원되지 않습니다.

리소스 소유자와 공용 클라이언트 애플리케이션이 동일한 장치에 있다고 가정

보안 공격에 가장 취약합니다.

3. 리소스 소유자 비밀번호 자격 증명

은 동일한 조직 내의 내부 또는 외부 애플리케이션과 같은 신뢰할 수 있는 클라이언트 애플리케이션에 적합합니다.

데스크톱 앱과 같이 로그인에 사용자 이름과 비밀번호를 사용하는 앱

인증 서버에서 액세스 토큰을 얻기 위해 사용자 이름/비밀번호를 인증 방법으로 사용

일반적으로 새로 고침 토큰을 지원하지 않습니다

리소스 소유자와 공개 고객은 동일한 장치에 있습니다

4. 클라이언트 자격 증명

클라이언트가 주요 서비스 API 애플리케이션을 호출하는 데 적합합니다(예: Baidu API Store, 서로 다른 프로젝트 간의 마이크로서비스가 서로 호출)

백엔드 채널만, 고객 자격 증명을 사용하여 액세스 토큰을 얻습니다

고객 자격 증명은 대칭 또는 비대칭 암호화를 사용할 수 있으므로 이 방법은 공유 비밀번호 또는 인증서를 지원합니다

3. 쿠키-세션 인증

쿠키-세션 인증 메커니즘은 다음과 같은 경우에 더 많이 노출됩니다. 먼저 J2EE를 배우려면 요청 인증을 위해 서버 측에 Session 객체를 생성하고 동시에 클라이언트의 브라우저 측에 Cookie 객체를 생성하여 클라이언트가 서버 측의 세션 객체와 일치하도록 가져옵니다. 상태 관리를 달성합니다. 기본적으로 쿠키는 브라우저를 닫을 때 삭제됩니다. 하지만 쿠키의 만료 시간을 수정하여 특정 기간 내에 쿠키를 유효하게 만들 수 있습니다.

그러나 이러한 쿠키 세션 기반 인증은 다양한 클라이언트 사용자의 증가로 인해 애플리케이션 자체를 확장하기가 어렵습니다. 독립 서버에서는 더 이상 이를 수행할 수 없으며, 사용자가 많아지면 세션 기반 인증 응용 프로그램의 문제가 노출됩니다.

세션 인증에 따른 문제:

1) 세션을 늘리면 서버 오버헤드가 증가합니다

각 사용자가 애플리케이션에 의해 인증된 후 애플리케이션은 사용자의 다음 요청을 용이하게 하기 위해 서버에 기록을 만들어야 합니다. 인증을 위해 세션은 일반적으로 인증된 사용자 수가 증가하면 서버측 오버헤드가 크게 증가합니다.

2) 분산 또는 다중 서버 환경에서의 적응성 부족

사용자 인증 후 서버는 인증 기록을 생성합니다. 인증 기록이 메모리에 저장되어 있으면 사용자가 다음 요청을 해야 한다는 의미입니다. 승인된 리소스를 이 서버에서 얻을 수 있으므로 분산 애플리케이션에서 로드 밸런서의 기능이 제한됩니다. 이는 또한 애플리케이션의 확장성을 제한한다는 의미이기도 합니다. 그러나 일부 서버는 이제 고정 세션을 설정하여 각 서버 간에 세션을 공유할 수 있습니다.

3) CSRF 공격에 취약

사용자 식별은 쿠키를 기반으로 하기 때문에 쿠키가 가로채면 사용자는 크로스 사이트 요청 위조 공격에 취약해집니다.

4. 토큰 인증

토큰 기반 인증 인증 메커니즘 http 프로토콜과 유사하며 서버 측에서 사용자의 인증 정보나 세션 정보를 유지할 필요가 없습니다. 즉, 토큰 인증 메커니즘을 기반으로 하는 애플리케이션은 사용자가 로그인하는 서버를 고려할 필요가 없으므로 애플리케이션 확장이 용이합니다.

프로세스:

사용자는 사용자 이름과 비밀번호를 사용하여 서버에 요청합니다.

서버는 사용자 정보를 확인합니다.

서버는 확인을 통해 사용자에게 토큰을 보냅니다.

클라이언트는 토큰을 저장하고 이 토큰 값을 다음과 같이 첨부합니다. 각 요청

서버는 토큰 값을 확인하고 데이터를 반환합니다.

이 토큰은 각 요청 중에 서버에 전달되어야 하며 요청 헤더에 저장되어야 합니다. 또한 서버는 CORS(Cross- Origin Resource Sharing) 정책은 일반적으로 서버 측 Access-Control-Allow-Origin에서 이를 수행할 수 있습니다.

5. JWT 인증 메커니즘(Json Web Token)

JWT는 개방형 표준(RFC 7519)으로 두 당사자 간의 통신을 위한 간결하고 독립적인 방법을 Json 객체 형태로 정의합니다. 정보를 안전하게 전달합니다. . 디지털 서명이 있기 때문에 이 정보는 신뢰할 수 있으며 JWT는 HMAC 알고리즘 또는 RSA 공개-개인 키 쌍을 사용하여 서명할 수 있습니다.

단순함

데이터 용량이 작고 전송 속도가 빠르기 때문에 URL, POST 매개변수 또는 HTTP 헤더를 통해 전송할 수 있습니다.

자체 포함

페이로드에는 사용자가 요구하는 모든 정보가 포함되어 있어 다중 전송을 방지합니다. times 데이터베이스 쿼리

다음 시나리오에서는 JSON 웹 토큰을 사용하는 것이 유용합니다.

승인: JWT를 사용하는 가장 일반적인 시나리오입니다. 사용자가 로그인하면 각 후속 요청에는 JWT가 포함되어 사용자가 해당 토큰에서 허용하는 경로, 서비스 및 리소스에 액세스할 수 있습니다. Single Sign-On은 오버헤드가 거의 없고 여러 도메인에서 쉽게 사용할 수 있기 때문에 현재 널리 사용되는 JWT의 기능입니다.

정보 교환: JSON 웹 토큰은 의심할 여지 없이 당사자 간에 정보를 안전하게 전송하는 좋은 방법입니다. 예를 들어 공개/개인 키 쌍을 사용하여 JWT에 서명할 수 있으므로 보낸 사람이 누구인지 확인할 수 있습니다. 또한, 헤더와 페이로드를 이용하여 서명을 계산하므로, 내용이 변조되지 않았는지 확인할 수도 있습니다.

JWT의 구조:

이 그림을 보면 JWT의 구조가 세 부분으로 나누어져 있으며 "."로 연결되어 있음이 분명합니다.:

Header:

header는 일반적으로 다음과 같이 구성됩니다. 토큰 유형("JWT")과 알고리즘 이름(예: HMAC SHA256 또는 RSA 등)의 두 부분으로 구성됩니다.

예:

그런 다음 Base64를 사용하여 이 JSON을 인코딩하여 JWT의 첫 번째 부분을 가져옵니다.

페이로드:

JWT의 두 번째 부분은 선언(요구 사항)이 포함된 페이로드입니다. 클레임은 엔터티(일반적으로 사용자) 및 기타 데이터에 대한 설명입니다. 선언에는 등록, 공개, 비공개의 세 가지 유형이 있습니다.

등록된 주장: 사전 정의된 주장 세트는 다음과 같습니다. 필수는 아니지만 권장됩니다. 예: iss(발급자), exp(만료 시간), sub(주제), aud(대상) 등

공개 주장: 원하는 대로 정의할 수 있습니다.

개인 청구: 정보 사용에 동의한 당사자 간에 정보를 공유하기 위해 사용되는 청구이며, 등록되거나 공개되지 않습니다.

예는 다음과 같습니다.

Base64는 페이로드를 인코딩하여 JWT의 두 번째 부분을 가져옵니다.

참고: 암호화되지 않은 경우 JWT의 페이로드나 헤더에 민감한 정보를 넣지 마세요.

서명:

서명 부분을 얻으려면 인코딩된 헤더, 인코딩된 페이로드, 비밀 키가 있어야 하며 서명 알고리즘은 헤더에 지정된 것인 다음 서명하면 됩니다.

예:

HMACSHA256(base64UrlEncode(header) + "." + base64UrlEncode(payload), secret)

서명은 전달 프로세스 중에 메시지가 변경되었는지 여부를 확인하는 데 사용됩니다. 개인 키를 사용하면 JWT의 보낸 사람이 누구인지 확인할 수도 있습니다.

JWT 토큰을 발견하면 JWT 공식 웹사이트로 이동하여 복호화할 수 있습니다. 아래는 공식 웹사이트에서 복호화된 데이터를 명확하게 볼 수 있습니다.

JWT에 대한 자세한 내용은 이 블로그로 이동할 수 있습니다:

https://www.cnblogs.com/cjsblog/p/9277677.html

참조:

https://www.jianshu.com/p/f8c43dcd8b69

https:// blog.csdn.net/alan_liuyue/article/details/88183267

https://www.cnblogs.com/cjsblog/p/9277677.html

관련 권장 사항: 웹 서버 보안

위 내용은 일반적으로 사용되는 몇 가지 웹 보안 인증 방법을 소개합니다.의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!