Feathers: Otentikasi selanjutnya

Menghentikan Paspor

Diskusi ini dimulai di #844 dan di https://github.com/feathersjs/feathers/issues/844#issuecomment -390123148 ​​merangkum poin-poin mengapa ini terjadi. Singkatnya, belum ada banyak pengembangan di PassportJS terutama di sekitar kerangka kerja pendukung selain Express dan sebagian besar kerangka kerja HTTP lainnya seperti Koa atau Hapi beralih menggunakan pustaka otentikasi yang lebih fleksibel dan minimalis (seperti https://github.com/simov/grant untuk oAuth). Ternyata juga hanya ada empat jenis strategi yang benar-benar dibutuhkan:

• Lokal (nama pengguna/kata sandi)
• JWT
• oAuth (+ token akses oAuth)
• Kunci API

Tanpa harus bekerja di sekitar Paspor, Feathers dapat dengan mudah duduk di atas perpustakaan HTTP apa pun dan mekanisme transportasi lainnya (seperti koneksi MQTT atau bahkan P2P) dengan pemisahan masalah yang jelas dan menyediakan mekanisme otentikasi yang jauh lebih mudah untuk dipahami dan disesuaikan.

Menggunakan params.authentication

Di sisi Feathers, menyetel params.authentication dalam panggilan layanan akan menjadi _hanya_ cara untuk memberikan informasi autentikasi. params.authentication akan berisi informasi yang diperlukan untuk mengotentikasi panggilan layanan dan akan dalam format misalnya { strategy: 'local', email: 'email', password: 'password' } yang sudah digunakan:

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

Penelepon (seperti REST atau transport websocket, hook atau unit test) akan bertanggung jawab untuk melewati params.authentication . Ini berarti tidak akan ada lagi kebingungan jika pengait authenticate berjalan untuk panggilan internal atau tidak atau dari mana informasi otentikasi sebenarnya berasal.

Kait authenticate

Kait authenticate akan terus ada. Ini akan mengambil daftar nama strategi dan juga akan

• Lanjutkan ke hook berikutnya dengan strategi pertama yang tidak menimbulkan kesalahan dan gabungkan nilai pengembaliannya (lihat di bawah) menjadi params

• Atau lempar kesalahan strategi pertama yang gagal jika semua strategi gagal

  Jika params.authentication berisi nama strategy hanya strategi itu yang akan dipanggil. Jika tidak semua strategi akan dipanggil. Jika params.authentication tidak disetel sama sekali, pengait akan

• Lempar kesalahan untuk panggilan eksternal

• Lanjutkan seperti biasa untuk panggilan internal (misalnya saat menyetel params.user secara manual)

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

Strategi otentikasi

Strategi otentikasi dasar adalah objek dengan metode authenticate yang mendapatkan data params.authentication dan mengembalikan objek yang berhasil atau menampilkan kesalahan jika tidak berhasil:

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);

Di kait authenticate , objek yang dikembalikan akan digabungkan ke dalam panggilan layanan params sehingga contoh ini akan menetapkan params.user .

Memperluas strategi

Strategi otentikasi dapat berisi dan memanggil metode tambahan secara internal. Strategi Feathers akan diimplementasikan sebagai kelas yang dapat disesuaikan melalui ekstensi (ini akan menggantikan Penguji dan pada dasarnya menggabungkan strategi dan penguji menjadi satu kelas):

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));

Penguraian HTTP

Strategi juga dapat menyediakan metode parse yang akan mendapatkan permintaan dan respons HTTP Node dasar dan harus mengembalikan nilai params.authentication (atau null ):

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;
  }
};

Pustaka HTTP kemudian dapat memutuskan apakah dan bagaimana mereka menggunakan metode tersebut untuk menyetel params.authentication atau mengotentikasi middleware mereka sendiri.

aplikasi.otentikasi

app.authenticate(authParams, [ strategies ]) akan menjalankan strategi yang diberikan dengan parameter otentikasi yang diberikan:

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

menyetel params.authentication dalam panggilan layanan akan menjadi _hanya_ cara untuk memberikan informasi autentikasi.

Bisakah Anda menjelaskan poin-poin desain tentang mengapa perlu menyediakan accessToken pada setiap panggilan service() ?

Ini hanya berlaku untuk server dan itulah yang secara implisit sudah terjadi melalui params.provider dan params.headers (dalam kasus soket web ini hanya header palsu) yang disetel untuk setiap panggilan layanan setelah otentikasi dikonfigurasi. Ini melanggar pemisahan Feathers antara kait dan layanan independen protokol transport dan mekanisme transportasi yang sebenarnya (seperti HTTP dengan Express atau Socket.io) dan membuatnya sangat membingungkan ketika misalnya hook authenticate('jwt') benar-benar berjalan dan untuk apa digunakan informasi otentikasinya.

Dari segi kegunaan, tidak ada yang benar-benar akan berubah untuk panggilan eksternal atau internal tetapi jika sekarang Anda ingin memicu pengait authenticate secara eksplisit di server, Anda selalu dapat mengatur params.authentication . Ini sangat penting untuk plugin kerangka kerja baru selain Express (misalnya Koa, HTTP2 atau antrian pesan) yang sekarang memiliki cara standar untuk meneruskan informasi otentikasi mereka ke mekanisme otentikasi Feathers.

Klien otentikasi masih akan membuat permintaan yang diautentikasi setelah masuk dengan memanggil app.authenticate() .

Terima kasih telah mengklarifikasi. Sangat menantikan pengujian dengan v3, terutama dengan klien socket.io React Native.

Pasti akan menaruh informasi tentang prarilis di sini. Cukup selesaikan klien otentikasi yang seharusnya menangani soket web yang diautentikasi dengan jauh lebih andal. Setelah selesai, akan sangat bagus jika Anda mendapatkan bantuan untuk menguji inti baru + otentikasi lokal dan jwt. oAuth harus segera menyusul setelah itu.

kapan versi 3 keluar?

Ada tanggapan atas pertanyaan saya?

Anda dapat melihat kemajuan saat ini di cabang master dan saya akan memposting posting blog ketika penguji beta dapat mencobanya. Statusnya adalah:

| Modul | Kode | Dokumen | CLI
| --- |:---:|:---:|---:|
| @feathersjs/otentikasi | | 100% | |
| @feathersjs/otentikasi-lokal | | 80% | |
| @featherjs/authentication-oauth | | 90%| |
| @feathersjs/otentikasi-klien | | 80%| |

Hai, ini bagus!

Fleksibilitas masa depan itu keren, tetapi saya belum memiliki kepercayaan diri dengan auth dalam proyek FeathersJS saya dan saya akan melalui proses yang membingungkan untuk membuatnya.

Memiliki implementasi autentikasi yang lengkap, teruji, dan aman berarti saya dapat dengan percaya diri beralih ke fitur. Salah satu alasan terbaik untuk menggunakan MeteorJS adalah integrasi akun yang sangat baik hingga ke klien.

Melihat melalui masalah FeatherJS, banyak tentang otentikasi, jadi saya senang pekerjaan ini mendarat!

Di mana dokumentasi terbaik (atau implementasi referensi) untuk sistem auth aman lengkap (auth lokal, kontrol akses, email, dll) di FeathersJS hari ini?

Inilah yang saya miliki sejauh ini - apakah ada yang lebih baik?

2018/02 - Menyiapkan verifikasi email di FeathersJS (pengulangan artikel 2017)
2018/02 - Repo dari artikel di atas
2017/01 - Cara mengatur verifikasi email di FeathersJS (rusak)
2018/06 - Otentikasi Vue dengan Feathersjs

Terima kasih sebelumnya!

Semua masalah terkait sekarang telah ditutup dan pra-rilis untuk Feathers v4 dengan semua perubahan yang diusulkan diimplementasikan tersedia untuk pengujian. Lihat panduan migrasi untuk informasi lebih lanjut.