소개
토큰 기반 인증은 요즘 웹 어디에서나 눈에 띄는. 대부분의 웹 회사에서는 토큰이 여러 사용자에 대한 인증을 처리하는 가장 좋은 방법입니다.
응용 프로그램에 대한 토큰 기반 인증을 선택할 때 매우 중요한 요소가 있습니다. 토큰의 주된 이유는 다음과 같습니다:
- 상태 비저장 및 확장 가능 서버
- 모바일 응용 프로그램 준비
- 다른 응용 프로그램에 인증 전달
- 추가 보안
토큰 기반 인증을 사용하는 사람은 누구입니까?
모든 주요 응용 프로그램 또는 웹 응용 프로그램에서 토큰을 사용할 가능성이 가장 높습니다. 페이스 북,트위터,구글+,ith,그리고 더 많은 사용 토큰과 같은 응용 프로그램.
정확히 어떻게 작동하는지 살펴 보겠습니다.
왜 토큰이
주위에 왔는지 토큰 기반 인증이 어떻게 작동하고 그 이점을 알기 전에 과거에 인증이 수행 된 방식을 살펴 봐야합니다.즉,사용자 이름과 암호로 사용자를 인증하면 다음 요청에 따라 응용 프로그램이 우리가 누구인지 알 수 없습니다. 우리는 다시 인증해야 할 것입니다.
우리의 응용 프로그램이 우리가 누구인지 기억하는 전통적인 방법은 서버에 사용자 로그인 정보를 저장하는 것입니다. 이 작업은 세션에서 일반적으로 메모리 또는 디스크에 저장된 몇 가지 다른 방법으로 수행 할 수 있습니다.
웹,응용 프로그램 및 모바일 응용 프로그램의 부상으로 인해 이러한 인증 방법은 특히 확장성에 문제가 있음을 보여주었습니다.
서버 기반 인증 문제
이 인증 방법에서는 몇 가지 주요 문제가 발생했습니다.
- 세션: 사용자가 인증될 때마다 서버는 서버에 레코드를 만들어야 합니다. 이 작업은 일반적으로 메모리에서 수행되며 인증하는 사용자가 많을 때 서버의 오버헤드가 증가합니다.
- 확장성:세션이 메모리에 저장되므로 확장성에 문제가 있습니다. 클라우드 공급자가 애플리케이션 부하를 처리하기 위해 서버를 복제하기 시작함에 따라 세션 메모리에 중요한 정보가 있으면 확장 능력이 제한됩니다.
- : 우리는 우리의 데이터가 여러 모바일 장치에서 사용할 수 있도록 우리의 응용 프로그램을 확장 할 때,우리는 교차 출처 자원 공유에 대해 걱정할 필요가(고전). 아약스 호출을 사용하여 다른 도메인(모바일 서버로 이동)에서 리소스를 확보 할 때 금지 된 요청에 문제가 발생할 수 있습니다.
- 우리는 또한 교차 사이트 요청 위조에 대한 보호를해야합니다. 그들은 이미 은행 사이트를 말과 다른 사이트를 방문 할 때이 활용 될 수있는 인증 할 수 있기 때문에 사용자는 보안 보안 공격에 취약합니다.
이러한 문제로 확장 성이 주된 문제 였기 때문에 다른 접근 방식을 시도하는 것이 합리적이었습니다.
토큰 기반 작동 방식
토큰 기반 인증은 상태 비저장입니다. 우리는 서버 또는 세션에서 우리의 사용자에 대한 정보를 저장하지 않습니다.
이 개념만으로도 서버에 정보를 저장해야하는 많은 문제를 해결할 수 있습니다.
세션 정보가 없다는 것은 사용자가 로그인한 위치에 대한 걱정 없이 응용 프로그램이 필요에 따라 더 많은 컴퓨터를 확장하고 추가할 수 있음을 의미합니다.
이 구현은 다를 수 있지만 요지는 다음과 같습니다:
- 사용자 요청 사용자 이름/비밀번호로 액세스
- 응용 프로그램 자격 증명 유효성 검사
- 응용 프로그램은 클라이언트에 서명 된 토큰을 제공합니다
- 클라이언트는 해당 토큰을 저장하고 모든 요청과 함께 보냅니다
- 서버는 토큰을 확인하고 데이터로 응답합니다
모든 단일 요청에는 토큰이 필요합니다. 이 토큰은 상태 비저장 요청의 아이디어를 유지할 수 있도록 Access-Control-Allow-Origin: *를 사용하여 모든 도메인의 요청을 수락하도록 서버를 설정해야합니다. 이 패키지에는 주 프로그램 바이너리와 미리 컴파일된 대수 및 자동 로드 모듈이 전부 들어있습니다.
일단 우리가 우리의 정보로 인증하고 우리의 토큰을 가지고 있다면,우리는이 토큰으로 많은 일을 할 수 있습니다.
권한 기반 토큰을 만들어 타사 응용 프로그램(사용하려는 새로운 모바일 앱)에 전달할 수도 있으며 데이터에 액세스 할 수 있지만 특정 토큰으로 허용 한 정보 만 사용할 수 있습니다.
토큰의 이점
상태 비저장 및 확장 가능
토큰은 클라이언트 측에 저장됩니다. 완전히 무국적 상태이며 확장 할 준비가되었습니다. 우리의로드 밸런서는 아무 곳이나 상태 또는 세션 정보가 없기 때문에 우리의 서버의에 따라 사용자를 통과 할 수 있습니다.
로그인한 사용자에 대한 세션 정보를 유지하려면에서 로그인한 동일한 서버(세션 선호도라고 함)로 해당 사용자를 계속 전송해야 합니다.
이로 인해 일부 사용자가 동일한 서버로 강제 이동되고 이로 인해 트래픽이 많이 발생할 수 있으므로 문제가 발생합니다.
그래도 걱정하지 마세요! 토큰 자체가 해당 사용자에 대한 데이터를 보유하고 있기 때문에 이러한 문제는 토큰과 함께 사라집니다.
보안
쿠키가 아닌 토큰은 모든 요청에서 전송되며,쿠키가 전송되지 않기 때문에 공격을 방지하는 데 도움이 됩니다. 특정 구현이 클라이언트 측의 쿠키 내에 토큰을 저장하더라도 쿠키는 인증 메커니즘이 아닌 저장 메커니즘에 불과합니다. 우리는 세션이 없기 때문에 조작 할 세션 기반 정보가 없습니다!
토큰도 설정된 시간 후에 만료되므로 사용자가 다시 로그인해야 합니다. 이것은 우리가 안전하게 유지하는 데 도움이됩니다. 또한 동일한 권한 부여를 기반으로 특정 토큰 및 토큰 그룹을 무효화 할 수있는 토큰 해지 개념이 있습니다.
확장 성(친구의 친구 및 권한)
토큰을 사용하면 다른 사람과 권한을 공유하는 응용 프로그램을 구축 할 수 있습니다. 예를 들어,우리는 페이스 북이나 트위터와 같은 우리의 주요 것들에 임의의 social 계정을 연결했다.
우리는 서비스를 통해 트위터에 로그인 할 때(의 버퍼를 가정 해 봅시다),우리는 버퍼가 우리의 트위터 스트림에 게시 할 수 있습니다.
토큰을 사용하여 타사 응용 프로그램에 선택적 권한을 제공하는 방법입니다. 사용자가 다른 응용 프로그램에 자신의 데이터에 대한 액세스 권한을 부여하려는 경우 우리는 심지어 우리 자신의 응용 프로그램을 구축하고 특별 권한 토큰을 나눠 줄 수 있습니다.
여러 플랫폼 및 도메인
우리는 이전에 코어에 대해 조금 이야기했습니다. 우리의 응용 프로그램과 서비스가 확장 될 때,우리는 모든 종류의 장치 및 응용 프로그램에 대한 액세스를 제공해야합니다(우리의 응용 프로그램이 가장 확실히 인기를 끌 것이기 때문에!).데이터만 제공하면,우리는 또한 디자인 선택에서 자산을 제공할 수 있습니다. 이것은 우리가 우리의 응용 프로그램에 대한 빠른 헤더 구성을 설정 한 후 코스가 제기하는 문제를 제거합니다.
Access-Control-Allow-Origin: *사용자가 유효한 토큰을 가지고있는 한 모든 도메인의 요청에 대해 데이터 및 리소스를 사용할 수 있습니다.
표준 기반
토큰을 만들 때 몇 가지 옵션이 있습니다. 다음 문서에서 이 주제에 대해 자세히 알아보겠습니다.
이 편리한 디버거 및 라이브러리 차트는 웹 토큰에 대한 지원을 보여줍니다. 당신은 다양한 언어에 걸쳐 지원의 큰 금액을 가지고 볼 수 있습니다. 이것은 당신이 미래에 그렇게하도록 선택하는 경우 실제로 인증 메커니즘을 전환 할 수 있다는 것을 의미합니다!
결론
이것은 토큰 기반 인증의 방법과 이유를 살펴본 것입니다. 보안의 세계에서 항상 그렇듯이,각 주제에 훨씬 더 많은 것이 있으며 사용 사례마다 다릅니다. 우리는 심지어 자체 대화를받을 가치가있는 확장성에 대한 몇 가지 주제에 뛰어 들었습니다.
이것은 높은 수준의 간략한 개요,그래서 놓친 아무것도 또는 당신이 문제에 대한 질문이 지적 주시기 바랍니다.
다음 기사에서 우리는 웹 토큰의 해부학을 살펴볼 것입니다.이 문서는”있는 그대로”제공되며 업데이트되지 않습니다