Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Trying to understand Solid-OIDC better

Aperta
#238 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
20/100
Tipo di issue
Documentazione
Chiarezza
Da chiarire
Stato di attività
Ferma
Ambito
authentication, security

Direzione di ricerca

Inizia dal Solid-OIDC primer e segui il passaggio UMA e il requisito di includere solid nel claim aud di OIDC. Confronta questi requisiti con il flusso proposto per la coppia di chiavi, l’ID-token e DPoP. Il lavoro è completato quando le questioni di compatibilità e la motivazione di sicurezza sono state affrontate o chiarite nella documentazione della specifica.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

I'm working on a decentralized app and Solid-OIDC is very close to the type of authentication system I need, and I'm wondering if I can adopt it instead of doing a home-grown system. Sorry this turned out long but I would appreciate any answers.

My current design is essentially:

  1. Client app creates a key pair, hashes the public key, and uses that key as the nonce in an OIDC flow with any OIDC provider (Google, GitLab, LastLogin, self-hosted, etc). The goal is for the OIDC provider to certify (perhaps unwittingly) that the sub owner controls the key pair, a la OpenPubKey.
  2. When the app makes requests to backend servers, it includes the ID token and a DPoP header for each request. Assuming the backend trusts the OIDC provider, requests are now authenticated, without requiring a previous relationship between the app and the backend server.

After reading through the Solid-OIDC primer, I see a couple areas of incompatibility due to extra steps. Since with auth extra steps often indicate potential security holes, I want to make sure I understand why they're necessary in the Solid case:

  1. Why is the UMA step necessary? My understanding is the purpose is that Alice could define specific permissions for Bob, then when Bob gets a token it's scoped to those permissions. But won't he always get the same permissions? Why not skip UMA altogether and just verify it's Bob making each request using a method similar to what I described above?
  2. Why is it necessary for the OP to add solid to aud? Does it matter if Bob wants to use his key pair to interact with multiple backends and multiple protocols? The main downside I see here is you can no longer use any OIDC provider, but must use a Solid-OIDC provider.
Lingua principale
Bikeshed
Stelle
26
Fork
14
Nessuna PR unita negli ultimi 30g

Guida per i contributori

Nessuna guida per i contributori indicizzata per questo repository

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di solid/solid-oidc

Tutte le issue di solid/solid-oidc

Issue simili

Altre issue su Security

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.