RESTful 원칙을 위반하지 않고 Angular에서 인증 및 인가를 위한 베스트 프랙티스

RESTful 원칙을 위반하지 않고 Angular에서 인증 및 인가를 위한 베스트 프랙티스

REST 및 Angular의 인증 및 인증에 대한 SO 스레드를 많이 읽어봤지만, 아직 원하는 것에 대한 훌륭한 솔루션이 있다고는 생각하지 않습니다.어느 정도 배경은 Angular에서 앱을 만들 예정입니다.지원하는 JS:

1. 게스트 접근 제한
2. 인증 후 애플리케이션에 대한 역할 기반 액세스
3. API를 통한 인증

REST API에 대한 모든 콜은 SSL을 통해 이루어져야 합니다.RESTful 원칙을 어기지 않고, 즉 서버에 저장된 세션 상태를 유지하지 않고 앱을 구축하고 싶습니다.물론 클라이언트측에서 이루어지는 모든 인증은 서버측에서 강화되어야 합니다.각 요구에 대해 상태 전체를 전달해야 하므로 REST 요구를 수신하는 백엔드 서버가 콜을 인증 및 인가할 수 있도록 일종의 토큰을 전달해야 합니다.

여기서 중요한 질문은 인증에 관한 것입니다.여기서 베스트 프랙티스는 무엇입니까?다양한 접근방식이 논의되고 있는 것 같습니다.여기서 발견한 것은 몇 가지입니다.

• http://broadcast.oreilly.com/2009/12/principles-for-standardized-rest-authentication.html
• http://frederiknakstad.com/2013/01/21/authentication-in-single-page-applications-with-angular-js/
• http://docs.aws.amazon.com/AmazonS3/latest/dev/RESTAuthentication.html

비슷한 질문이 있었다(Angular).JS Best Practice Application Authentication)을 사용하지만, 제가 잘못 알고 있는 경우가 아니라면 서버 세션을 사용해야 한다는 것을 의미하는 것으로 보이며, 이는 RESTful 원칙을 위반하는 것입니다.

Amazon AWS와 George Reese 기사에 대한 나의 주된 관심사는 소비자가 최종 사용자가 아니라 프로그램이라고 가정하는 것 같다는 것이다.공유 비밀은 프로그래머에게 미리 발행할 수 있으며 프로그래머는 이를 사용하여 콜을 부호화할 수 있습니다.여기에서는 그렇지 않습니다.사용자 대신 앱에서 REST API를 호출해야 합니다.

이 접근법으로 충분할까요?세션 리소스가 있다고 가정합니다.

POST /api / 세션

사용자에 대한 새 세션 생성

세션을 작성하려면 "username" 및 "password"를 포함하는 JSON 개체를 POST해야 합니다.

{
    "email" : "austen@example.com",
    "password" : "password"
}

컬 예시

curl -v -X POST --data '{"username":"austen@example.com","password":"password"}' "https://app.example.com/api/session" --header "Content-Type:application/json"

대답

HTTP/1.1 201 Created {
    "session": {
        "id":"520138ccfa4634be08000000",
        "expires":"2014-03-20T17:56:28+0000"
    }
}

상태 코드

• 201 - 생성, 신규 세션 확립
• 400 - 잘못된 요청, JSON 개체가 잘못되었거나 필요한 정보가 없습니다.
• 401 - 무허가, 이메일/비밀번호 확인 콤보
• 403 - 접근 거부, 비활성화된 계정 또는 라이선스가 비활성화됨

명확하게 하기 위해 하테오아스의 세부 사항은 생략합니다.백엔드에는 새로운 기간 한정 세션키가 생성되어 사용자와 관련지어집니다.이후 요청 시 HTTP 헤더의 일부로 전달할 수 있습니다.

Authorization: MyScheme 520138ccfa4634be08000000 

그러면 백엔드 서버는 요청에서 이를 요약하고 관련 사용자를 검색하여 요청에 대한 인가 규칙을 적용합니다.세션의 유효기간도 갱신될 것입니다.

이 모든 것이 SSL을 통해 일어나고 있는 경우, 보호해야 할 공격에 대해 문호를 개방하고 있습니까?세션 키를 추측하여 헤더에 배치할 수 있습니다.따라서 사용자 GUID를 세션키에 추가하여 브루트 포스 공격을 더욱 방지할 수 있습니다.

내가 적극적으로 프로그램을 짜온 지 몇 년이 지났고, 나는 여기서 다시 그네로 돌아가는 중이다.제가 둔감하거나 불필요하게 바퀴를 다시 만든다면 사과드립니다. 지금까지 읽은 내용을 바탕으로 제 아이디어를 커뮤니티에 전달하고 리트머스 테스트를 통과했는지 살펴보기를 바랄 뿐입니다.

REST 인증에 대해 묻는다면 Amazon Web Services를 따르며 기본적으로 "그렇게 하세요"를 제안합니다. 왜일까요?왜냐하면 "군중의 지혜"의 관점에서 AWS는 문제를 해결하고, 많은 사람들이 사용하고, 분석하며, 가장 안전한 요청을 하는 것에 대해 가장 많이 알고, 관심을 갖는 사람들에 의해 조사되기 때문입니다.또한 보안은 "수레바퀴를 다시 만들지 않는" 좋은 장소입니다.'어깨에 올라서야 한다'는 측면에서는 AWS보다 못한 결과를 얻을 수 있다.

현재 AWS는 토큰 기술을 사용하지 않고 공유 비밀과 페이로드에 기반한 보안 해시를 사용합니다.이것은 (모든 정규화 프로세스 등을 포함한) 보다 복잡한 구현이라고 할 수 있습니다.

하지만 그것은 효과가 있다.

단점은 애플리케이션이 개인 공유 비밀(즉, 비밀번호)을 유지해야 하고 서버가 일반 텍스트 버전의 비밀번호에 액세스할 수 있어야 한다는 것입니다.이는 일반적으로 암호가 암호화된 상태로 저장된 후 적절한 암호를 해독함을 의미합니다.그 때문에, 시큐어 해싱 기술에 비해, 서버측의 키 관리나 그 외의 작업이 한층 더 복잡해집니다.

물론 토큰 패스 기법의 가장 큰 문제는 맨 인 더 미들 공격과 리플레이 공격이다.SSL은 이러한 문제를 대부분 자연스럽게 완화합니다.

물론 OAuth 패밀리에 대해서도 고려해야 합니다.OAuth 패밀리는 특히 상호 운용성에 관한 독자적인 문제를 안고 있습니다.그러나, 이것이 주된 목표가 아닌 경우는, 이 기술은 확실히 유효합니다.

애플리케이션에 있어서, 토큰 리스는 큰 문제가 되지 않습니다.사용 중인 응용 프로그램은 리스 기간 내에 작동하거나 갱신할 수 있어야 합니다.그러기 위해서는 사용자 credential을 유지하거나 사용자 credential을 재프롬프트해야 합니다.토큰을 다른 리소스와 마찬가지로 퍼스트 클래스 리소스로 취급하면 됩니다.가능한 경우 다른 정보를 요청과 관련지어 토큰(브라우저 시그니처, IP 주소)에 번들하여 로컬성을 적용합니다.

같은 요구를 2회 송신할 수 있는 (잠재적인) 재생 문제에 대해서는, 아직 미해결인 채로 있습니다.일반적인 해시 구현에서는 타임스탬프는 요청 수명을 괄호로 묶을 수 있는 시그니처의 일부입니다.이 경우 그것은 다르게 해결된다.예를 들어, 각 요구는 시리얼 ID 또는 GUID로 송신할 수 있습니다.또, 요구가 재생되고 있는 것을 기록해 재발하지 않게 할 수 있습니다.다른 기술들이 있어요.

여기에서는 Angular로 작성된 인증 및 로그인 서비스에 대한 놀라운 기사를 소개합니다.

https://medium.com/opinionated-angularjs/7bbf0346acec

이 SO 질문은 REST에 대한 저의 이해를 요약하는 데 도움이 됩니다.

세션은 정말 RESTfulness를 위반합니까?

서버측에서 아직 상태를 작성 중인 세션에 토큰을 저장하는 경우(이는 세션이 보통1개의 서버에만 저장되기 때문에 스틱세션 또는 기타 솔루션을 사용하여 이 문제를 완화할 수 있습니다.

RESTful 서비스를 만들기 위한 당신의 이유를 알고 싶습니다만, 이것은 그다지 큰 문제가 아닐지도 모릅니다.

모든 요구와 함께 본문에 토큰을 송신하는 경우(모든 것이 SSL로 암호화되어 있기 때문에 문제 없습니다), 상태를 사전에 파악하지 않고 임의의 수의 서버(부하 분산)로 요구를 처리할 수 있습니다.

요컨대 RESTful 구현을 목표로 하는 것은 좋은 목표라고 생각합니다만, 순수하게 스테이트리스인 것은, 인증과 인증의 검증에 관해서 한층 더 복잡함을 낳습니다.

지금까지 REST를 염두에 두고 백엔드를 구축해 왔습니다.URI는 타당하고 올바른 HTTP 동사를 사용하지만 인증의 단순성을 위해 세션에서 토큰을 사용합니다(여러 서버를 사용하지 않는 경우).

네가 올린 링크에서 읽었어 Angular는JS one은 클라이언트에만 초점을 맞추고 이 문서에서 서버를 명시적으로 다루지 않는 것 같습니다.또 다른 JS one에 링크하는 것 같습니다(저는 노드 사용자가 아니므로 여기서 해석이 틀리다면 양해 바랍니다).그러나 서버는 클라이언트에 의뢰하여 어느 수준의 인가 수준을 전달하고 있는 것은 분명 좋은 생각이 아닙니다.

언급URL : https://stackoverflow.com/questions/22488393/best-practices-for-authentication-and-authorization-in-angular-without-breaking