Feathers: 인증 다음

여권 폐기

이 토론은 #844에서 시작되었으며 https://github.com/feathersjs/feathers/issues/844#issuecomment -390123148에서 이것이 발생하는 요점을 요약합니다. 요컨대, 특히 Express 이외의 프레임워크를 지원하는 것과 관련하여 PassportJS에서 많은 개발이 이루어지지 않았으며 Koa 또는 Hapi와 같은 대부분의 다른 HTTP 프레임워크는 https://github.com/simov/grant와 같은 보다 유연하고 미니멀한 인증 라이브러리를 사용하도록 이동했습니다. oAuth용). 또한 실제로 필요한 전략에는 네 가지 유형만 있음이 밝혀졌습니다.

• 로컬(사용자 이름/비밀번호)
• JWT
• oAuth(+ oAuth 액세스 토큰)
• API 키

Passport를 해결할 필요 없이 Feathers는 문제를 명확하게 구분하여 HTTP 라이브러리 및 기타 전송 메커니즘(예: MQTT 또는 P2P 연결) 위에 쉽게 배치할 수 있으며 훨씬 더 쉽게 이해하고 사용자 정의할 수 있는 인증 메커니즘을 제공할 수 있습니다.

params.authentication

Feathers 측에서는 서비스 호출에서 params.authentication 를 설정하는 것이 인증 정보를 제공하는 _유일한_ 방법입니다. params.authentication 에는 서비스 호출을 인증하는 데 필요한 정보가 포함되며 이미 사용 중인 { strategy: 'local', email: 'email', password: 'password' } 형식입니다.

// Call `find` with a given JWT
app.service('messages').find({
  authentication: {
    strategy: 'jwt',
    accessToken: 'someJWT'
  }
});

호출자(예: REST 또는 websocket 전송, 후크 또는 단위 테스트)는 params.authentication 전달을 담당합니다. 이것은 authenticate 후크가 내부 호출에 대해 실행되는지 여부 또는 인증 정보가 실제로 어디에서 오는지 더 이상 혼란이 없을 것임을 의미합니다.

authenticate 후크

authenticate 후크는 계속 존재합니다. 전략 이름 목록이 필요하며 다음 중 하나를 수행합니다.

• 오류를 발생시키지 않은 첫 번째 전략으로 다음 후크를 계속하고 반환 값(아래 참조)을 params 병합합니다.

• 또는 모든 전략이 실패한 경우 실패한 첫 번째 전략의 오류를 던집니다.

  params.authentication 에 strategy 이름이 포함된 경우 해당 전략만 호출됩니다. 그렇지 않으면 모든 전략이 호출됩니다. params.authentication 가 전혀 설정되지 않은 경우 후크는

• 외부 호출에 대한 오류 발생

• 내부 통화에 대해 평소와 같이 계속합니다(예: params.user 수동으로 설정하는 경우).

app.service('messages').hooks({
  before: authenticate('jwt', 'local', 'anonymous')
});

인증 전략

기본 인증 전략은 params.authentication 의 데이터를 가져오고 성공 개체를 반환하거나 성공하지 못한 경우 오류를 throw하는 authenticate 메서드가 있는 개체입니다.

const { Forbidden } = require('@feathersjs/errors');

const daveStrategy = {
  async authenticate (authParams) {
    const { username, password } = authParams;

    if (username === 'david' && password === 'secret') {
      return {
        user: {
          name: 'Dave',
          admin: true
        }
      };
    }

    throw new Forbidden('Not super Dave');
  }
};

app.authentication.registerStrategy('superdave', daveStrategy);

authenticate 후크에서 반환된 개체는 params 서비스 호출에 병합되므로 이 예제에서는 params.user 합니다.

확장 전략

인증 전략은 내부적으로 추가 메서드를 포함하고 호출할 수 있습니다. Feathers 전략은 확장을 통해 사용자 정의할 수 있는 클래스로 구현됩니다(이는 검증자를 대체하고 기본적으로 전략과 검증자를 단일 클래스로 결합합니다):

class LocalStrategy {
  constructor(app);
  async findUser(authParams);
  async comparePassword(user, password);
  async authenticate (authParams);
}

class MyLocalStrategy extends LocalStrategy {
  async findUser(authParams);
}

app.authentication.registerStrategy('local', new MyLocalStrategy(app));

HTTP 파싱

전략은 기본 노드 HTTP 요청 및 응답을 가져오고 params.authentication (또는 null )에 대한 값을 반환해야 하는 parse 메서드를 제공할 수도 있습니다.

const daveStrategy = {
  async authenticate (authParams) {
    throw new Forbidden('Not super Dave');
  }

  async parse (req, res) {
    const apiKey = req.headers['x-super-dave'];

    if (apiKey) {
      return {
        strategy: 'superdave',
        apiKey
      }
    }

    return null;
  }
};

그런 다음 HTTP 라이브러리는 이러한 메서드를 사용하여 params.authentication 하거나 자체 미들웨어를 인증하는지 여부와 방법을 결정할 수 있습니다.

앱 인증

app.authenticate(authParams, [ strategies ]) 는 주어진 인증 매개변수로 주어진 전략을 실행합니다:

// Will return the user for a JWT (on the server)
const { user } = app.authenticate({ accessToken }, 'jwt');

서비스 호출에서 params.authentication 를 설정하는 것은 인증 정보를 제공하는 _유일한_ 방법입니다.

모든 service() 호출에 accessToken 를 제공해야 하는 이유에 대해 설계 포인트를 살펴보실 수 있습니까?

이것은 서버에만 적용되며 인증이 구성되면 모든 서비스 호출에 대해 설정된 params.provider 및 params.headers (웹 소켓의 경우 이는 가짜 헤더일 뿐입니다)를 통해 이미 암시적으로 발생합니다. 이것은 전송 프로토콜 독립 후크 및 서비스와 실제 전송 메커니즘(예: Express 또는 Socket.io가 있는 HTTP) 사이의 Feathers 분리를 깨고 authenticate('jwt') 후크가 실제로 실행되고 무엇에 사용되는지를 매우 혼란스럽게 만들었습니다. 그 인증 정보.

유용성 측면에서 외부 또는 내부 호출에 대해 실제로 변경되는 것은 없지만 이제 서버에서 명시적으로 authenticate 후크를 트리거하려면 항상 params.authentication 설정할 수 있습니다. 이것은 인증 정보를 Feathers 인증 메커니즘에 전달하는 표준화된 방법이 있는 Express 이외의 새로운 프레임워크 플러그인(예: Koa, HTTP2 또는 메시징 대기열)에 특히 중요합니다.

인증 클라이언트는 app.authenticate() 를 호출하여 로그인한 후에도 인증된 요청을 계속합니다.

명확히 해 주셔서 감사합니다. v3, 특히 socket.io React Native 클라이언트를 사용한 테스트가 매우 기대됩니다.

여기에 프리릴리즈에 대한 정보를 확실히 넣을 것입니다. 인증된 웹 소켓을 훨씬 더 안정적으로 처리해야 하는 인증 클라이언트를 마무리하기만 하면 됩니다. 일단 완료되면 새로운 코어 + 로컬 및 jwt 인증을 테스트하는 데 도움을 받는 것이 좋습니다. oAuth는 그 이후에 곧 따라야 합니다.

3버전은 언제 나오나요?

내 질문에 대한 답변이 있습니까?

현재 진행 상황은 마스터 브랜치에서 확인할 수 있으며 베타 테스터가 사용해 볼 수 있을 때 블로그 게시물을 올리도록 하겠습니다. 상태는 다음과 같습니다.

| 모듈 | 코드 | 문서 | CLI
| --- |:---:|:---:|---:|
| @feathersjs/인증 | ✅| 100% | ❌|
| @feathersjs/authentication-local | ✅ | 80% | ❌|
| @featherjs/인증-oauth | ✅| 90%| ❌|
| @feathersjs/인증 클라이언트 | ✅ | 80%| ❌|

안녕하세요, 이것은 훌륭합니다!

미래의 유연성은 훌륭하지만 아직 FeathersJS 프로젝트의 인증에 확신이 없으며 이를 생성하기 위해 혼란스러운 과정을 겪고 있습니다.

완벽하고 테스트를 거친 안전한 인증 구현을 통해 자신 있게 기능을 진행할 수 있습니다. MeteorJS를 사용하는 가장 좋은 이유 중 하나는 클라이언트에 대한 완벽한 계정 통합이었습니다.

FeatherJS 문제를 살펴보면 많은 사람들이 인증에 관한 것이므로 이 작업이 착륙하게 되어 매우 기쁩니다!

오늘날 FeathersJS에서 완전한 보안 인증 시스템(로컬 인증, 액세스 제어, 이메일 등)을 위한 최고의 문서(또는 참조 구현)는 어디에 있습니까?

이것이 내가 지금까지 가지고 있는 것입니다. 더 나은 것이 있습니까?

2018/02 - FeathersJS에서 이메일 확인 설정(2017년 기사 재해시)
2018/02 - 위 기사의 리포지토리
2017/01 - FeathersJS에서 이메일 확인을 설정하는 방법(손상됨)
2018/06 - Feathersjs를 사용한 Vue 인증

미리 감사드립니다!

이제 모든 관련 문제가 종료되었으며 제안된 모든 변경 사항이 구현된 Feathers v4의 시험판을 테스트할 수 있습니다. 자세한 내용은 마이그레이션 가이드 를 참조하세요.