09 maj 2025·8 min
Hur man bygger en mobilapp för digitala pass och åtkomstkort
Lär dig planera, bygga och säkra en mobilapp för digitala pass och åtkomstkort med QR och NFC, inklusive utfärdandeflöden, testning och utrullningstips.
Lär dig planera, bygga och säkra en mobilapp för digitala pass och åtkomstkort med QR och NFC, inklusive utfärdandeflöden, testning och utrullningstips.
Innan du väljer QR vs NFC — eller Apple Wallet vs ett pass i appen — bli tydlig med vad ett “digitalt pass” betyder i ditt projekt. En enda app kan utfärda anställdas accessbrickor, medlemskort, evenemangsbiljetter eller tidsbegränsade besökspass, och varje typ har olika krav för identitetskontroll, återkallelse och hur ofta credentialen förändras.
Skriv ner vad som händer från början till slut, inklusive vem som godkänner och vad “framgång” är vid dörren.
Till exempel:
Lista de personer som berörs av systemet och deras mål:
Välj mått som kartlägger både användarupplevelse och drift:
Om dörrar eller skannrar måste fungera utan nätkontakt, definiera hur länge offline‑åtkomst förblir giltig (minuter, timmar, dagar) och vad som händer när ett pass återkallas medan läsaren är offline. Det här valet påverkar credential‑design, reader‑konfiguration och er säkerhetsmodell senare.
Ett digitalt pass är bara så bra som ögonblicket när det skannas eller trycks mot läsaren. Innan du bygger gränssnitt, bestäm vad läsaren kommer att acceptera och vad användarna pålitligt kan visa upp i verkliga förhållanden (trängsel, dålig täckning, kallt väder, handskar).
QR‑koder är universella och billiga: valfri kamerabaserad skanner — eller till och med en telefonkamera för visuell verifiering — kan fungera. De är långsammare per person än tapp och enklare att kopiera om du förlitar dig på statiska koder.
NFC (tapp) känns som en fysisk badge‑ersättning. Det är snabbt och välbekant, men förutsätter kompatibla dörrläsare och att enheterna stöder det. Det finns också plattformsbegränsningar (t.ex. om du kan emulera ett kort eller måste använda Wallet‑baserade credentials).
Bluetooth (hands‑free) kan förbättra tillgänglighet och hastighet, men är mer komplext att finjustera (räckvidd, interferens) och kan skapa “varför öppnade det inte?”‑ögonblick.
Engångslänkar / in‑app‑koder (roterande koder, signerade tokens) är bra fallback‑alternativ och kan minska kloningsrisk. De kräver app‑logik och kan, beroende på design, kräva periodisk nätåtkomst.
Matcha varje metod mot: befintlig läsar‑hårdvara, genomströmning (personer/minut), offline‑behov, budget och supportbörda. Exempel: högtrafikerade turnstiles kräver ofta NFC‑hastighet; temporära evenemangsentréer kan tolerera QR.
Ett praktiskt mönster är NFC som primärt val + QR som fallback. NFC hanterar hastigheten; QR täcker äldre telefoner, trasig NFC eller platser utan NFC‑läsare.
Dokumentera exakt vad som händer när:
Dessa beslut formar reader‑integration, säkerhetspolicy och support‑playbook senare.
Var credentialen “bor” är ett tidigt beslut eftersom det påverkar readerintegration, användarupplevelse och säkerhetsbegränsningar.
Ett in‑app‑pass renderas och hanteras av er app. Det ger maximal kontroll över UI, autentisering, analys och specialflöden.
Fördelar: full branding och anpassade skärmar, flexibel autentisering (biometri, step‑up), rikare kontext (karta, instruktioner) och enklare stöd för flera credentialtyper.
Nackdelar: användaren måste öppna appen (eller använda en widget/quick action ni bygger), OS‑nivå åtkomst från låsskärm är begränsad, och offline‑beteendet är helt ert ansvar.
Wallet‑pass (t.ex. PKPass på iOS) är välkända och designade för snabb presentation.
Fördelar: hög förtroendefaktor och upptäckbarhet, åtkomst från låsskärm/snabb åtkomst, OS‑hantering för presentation och snabbt "visa koden"‑beteende.
Nackdelar: snävare plattformsbegränsningar (stödda streckkod-/NFC‑format, begränsad UI), uppdateringar följer Wallet‑regler, och ni kan behöva Apple/Google‑specifik setup (certifikat, issuer‑konfiguration, ibland granskning). Djup telemetri är också svårare.
Använd Wallet när hastighet, igenkänning och ”alltid tillgänglig” presentation är viktig (besökare, evenemang, enkla dörrflöden). Använd in‑app när du behöver starkare identitetskontroller, rikare arbetsflöden eller komplex credential‑logik (anställda med flera site‑åtkomster, godkännanden, rollbaserad åtkomst).
Om ni tjänar flera organisationer, planera för mallar per org: logotyper, färger, instruktioner och olika datafält. Vissa team levererar båda: ett Wallet‑pass för snabb entré plus en in‑app‑credential för administration och support.
Oavsett behållare, definiera livscykelåtgärder ni kan trigga:
Håll dessa operationer konsekventa mellan in‑app och Wallet så driftsteamet kan hantera åtkomst utan manuella workaround.
En tydlig datamodell gör resten av systemet förutsägbart: att utfärda ett pass, validera det vid en läsare, återkalla det och utreda incidenter ska vara enkla frågor—inte gissningar.
Börja med en liten uppsättning “first‑class” objekt och bygg ut bara när det behövs:
Denna separation hjälper när en användare byter telefon: passet kan förbli konceptuellt samma medan credentials roterar och devices ändras.
Definiera explicita tillstånd och tillåt bara avsiktliga övergångar:
Exempel på övergångar: pending → active efter verifiering; active → suspended vid policyöverträdelse; active → revoked när anställning upphör; suspended → active efter admin‑återställning.
Planera unika ID på två nivåer:
Bestäm hur läsare mappar token till åtkomsträtt: direktuppslag (token → user → policy) eller token → policy‑grupp (snabbare på kanten). Håll identifierare icke‑gissbara (slumpmässiga, inte sekventiella).
Behandla auditloggar som append‑only och separera dem från tabeller för “nuvarande tillstånd”. Minst bör du logga:
Dessa händelser blir er källa för felsökning, regelefterlevnad och missbruksupptäckt.
Ett digitalt pass‑projekt lyckas eller misslyckas på “de första 5 minuterna”: hur snabbt en verklig person kan registrera sig, få en credential och förstå vad som gäller.
De flesta team stödjer en mix av dessa steg beroende på säkerhet och driftsstorlek:
Ett praktiskt mönster är: inbjudningslänk → verifiera e‑post/SMS → (valfritt) SSO → utfärda pass.
Designa utfärdandet så att användarna slipper “lista ut det”:
Håll text och instruktioner extremt tydliga: vad passet används för, var det kommer att visas (app vs wallet) och vad man gör vid dörren.
Planera detta tidigt för att undvika supportärenden:
Skriv vänliga, specifika meddelanden för:
Bra utfärdande är inte bara “skapa ett pass” — det är en komplett, begriplig resa med förutsägbara återställningsvägar.
Digitala pass är bara så pålitliga som identiteten och behörigheterna bakom dem. Behandla autentisering (vem du är) och auktorisation (vad du får göra) som förstklassiga produktfunktioner, inte bara som rör.
Välj inloggningsmetod efter publik och risknivå:
Om ni stödjer flera tenants, bestäm tidigt om en användare kan tillhöra mer än en tenant och hur de byter kontext.
Definiera roller i klartext (t.ex. Pass Holder, Front Desk, Security Admin, Auditor), och mappa dem till rättigheter:
Håll auktorisationskontroller på servern (inte enbart i UI) och logga varje känslig åtgärd med vem, vad, när, var (IP/enhet) samt ett motiv‑fält för manuella admin‑åtgärder.
Använd kortlivade access‑tokens med refresh‑tokens och stöd säker återinloggning via biometri (Face ID/Touch ID) för att visa passet.
För högre säkerhetsinstallationer, lägg till device binding så en credential är giltig endast på registrerade enheter. Det gör det också svårare att använda kopierade token på andra enheter.
Admin‑verktyg behöver extra skydd:
Dokumentera dessa policyer i ett internt runbook och länka det från admin‑UI (t.ex. /docs/admin-security) så drift förblir konsekvent.
Säkerhet för digitala pass handlar mindre om att “gömma QR‑koden” och mer om att bestämma vad en läsare får lita på. Rätt modell beror på anslutning, läsarens kapacitet och hur snabbt ni behöver återkalla åtkomst.
Vanligtvis har ni tre mönster:
Statiska QR‑koder är lätta att dela och skärmdumpa. Föredra roterande eller tidsbegränsade koder:
Om ni måste stödja offline QR‑validering, gör QR:en tidsbegränsad och signerad, och acceptera att verklig återkallelse inte blir möjlig utan läsar‑synk.
För NFC, planera var hemligheterna förvaras och hur de används:
Bestäm tidigt hur snabbt ett återkallat pass måste sluta fungera (sekunder, minuter, timmar). Det kravet styr arkitekturen:
Skriv ner detta som ett säkerhets‑ och drift‑SLO eftersom det påverkar reader‑konfiguration, backend‑tillgänglighet och incidenthantering.
Här möter era digitala pass verkligheten: turnstiles, dörrkontroller, hissläsare och handhållna skannrar. Integrationsval påverkar tillförlitlighet, hastighet och vad som händer vid nätverksbortfall.
Vanliga integrationssätt inkluderar:
Definiera mål tidigt (t.ex. “beslut om upplåsning på under 300–500 ms”). Dokumentera även vad “offline” betyder för varje plats:
Skriv ner systemen och data ni måste synka:
Ett enkelt “source of truth”‑diagram i era interna docs sparar veckor senare.
Behandla läsare som produktionsinfrastruktur. Mät:
Gör dessa synliga i ett ops‑dashboard och skicka kritiska problem till on‑call. Ett snabbt “varför nekades jag?”‑flöde minskar supporttryck vid utrullning.
Ett digitalt pass‑system lever eller dör med sin backend: den utfärdar credentials, kontrollerar giltighet och spelar in vad som hände — snabbt och tillförlitligt — när folk står vid en dörr.
Börja med ett litet set endpoints ni kan utveckla:
POST /v1/passes/issue — skapa ett pass för en användare, returnera en aktiveringslänk eller pass‑payloadPOST /v1/passes/refresh — rotera identifierare / uppdatera rättigheter, returnera senaste passdataPOST /v1/passes/validate — verifiera en QR/NFC‑token som presenteras vid en läsare (online‑läsare)POST /v1/passes/revoke — nullställ ett pass omedelbart (förlorad telefon, avslutad åtkomst)POST /v1/events — logga inpasseringsförsök och utfall (accepterat/nekad/fel)Även om en del validering händer på enheten eller läsaren, behåll en server‑sida validerings‑API för revision, fjärråterkallelse och “break glass”‑operationer.
Om ni stödjer Apple Wallet (PKPass) eller andra signerade payloads, behandla signeringsnycklar som produktionshemligheter:
Ett praktiskt mönster är en dedikerad “signeringstjänst” med ett snävt gränssnitt (t.ex. “signera pass‑payload”), isolerad från resten av applikationen.
Inpasseringstoppar är förutsägbara (09:00, evenemangsstart). Planera för bursty reads:
Använd cache för återkallelselistor och rättighetsuppslag, lägg till retries med idempotensnycklar för utfärdande, och köa icke‑kritiska jobb (analytics, notiser) så validering förblir snabb. Om läsare går online, håll valideringslatensen låg genom att undvika pratiga beroenden.
Minimera lagrade personuppgifter: föredra interna user‑ID över namn/e‑post i passposter och händelser. Definiera retention i förväg (t.ex. behåll inpasseringsloggar 30–90 dagar om inte längre krävs) och separera operativa loggar från säkerhets/audit‑loggar med striktare åtkomstkontroller.
Om ni itererar snabbt — adminportal, utfärdande‑API:er och en initial mobilupplevelse — kan verktyg som Koder.ai hjälpa er att prototypa och leverera ett end‑to‑end‑passystem via chat samtidigt som ni behåller en produktionskvalitets stack under ytan (React för web, Go + PostgreSQL för backend, Flutter för mobil). Det är särskilt användbart för att skapa en fungerande pilot (inklusive deployment/hosting, egna domäner och snapshots med rollback) och sedan exportera källkoden när ni är redo att integrera med en specifik ACS eller on‑prem gateway.
Ett digitalt pass lyckas eller misslyckas på skärmen folk ser vid dörren. Optimera för tre ögonblick: första uppsättningen, “visa mitt pass nu” och “något gick fel—hjälp mig återhämta mig snabbt.”
Om ni stödjer Apple Wallet / Google Wallet, tydliggör om appen krävs efter provisioning. Många användare föredrar “lägg till i wallet och glöm”.
Designa “visa pass”‑skärmen som en boardingkort: omedelbar, tydlig och lätt att läsa.
Undvik att gömma passet i menyer. Ett persistent hemkort eller en primär knapp minskar dröjsmål vid dörren.
Stöd stora textstorlekar, Dynamic Type, skärmläsare‑etiketter (“Access pass QR kod”) och högkontrast teman. Behandla fel som en del av UX: kamera blockerad, NFC av, pass utgånget eller läsare svarar inte. Varje tillstånd bör innehålla enkla instruktioner (“Aktivera kamera i Inställningar”) och en fallback‑åtgärd.
Tidszoner och enhetsklockans avvikelse kan få tidsbaserade pass att se “fel” ut, så visa tider med evenemangets tidszon och lägg till en diskret “Senast synkroniserad”‑indikator.
Planera också för: flygplansläge, fladdrig täckning i lobbyn, indragna behörigheter (kamera/NFC) och låg‑batteri‑tillgänglighetslägen. En liten “Felsök”‑länk till /help/mobile-pass kan förebygga supporttoppar vid rusning.
Att testa en mobil åtkomstkortapp handlar inte bara om “öppnar det” utan om “öppnar det varje gång, under press”. Behandla testning som en produktkrav, inte bara en slutkontrollista.
Börja med en matris som speglar vad användarna faktiskt bär och vilka dörrar ni faktiskt använder:
Inkludera både in‑app‑credentials och wallet‑flöden (Apple Wallet pass / Google Wallet pass), eftersom PKPass‑beteende och system‑UI‑timing kan skilja sig från er app.
Lab‑perfekta skanningar matchar inte verkliga köer. Kör “rusningstester” där 20–50 personer visar pass snabbt, back‑to‑back, med:
Mät median tid till entré, felprocent och återhämtningstid (vad användaren gör härnäst).
Testa aktivt:
Ha en staging‑miljö med testläsare och syntetisk trafik som simulerar peak. Verifiera utfärdande, uppdatering och återkallelse under belastning, och säkerställ att loggningen låter er spåra “tapp/skanning → beslut → dörr‑resultat” end‑to‑end.
En lyckad lansering handlar mindre om en stor release och mer om förutsägbar entré vid varje dörr, varje dag. Planera för kontrollerad utrullning, tydliga supportvägar och mätningar som visar var friktion gömmer sig.
De flesta organisationer mår bäst av en fasad utrullning:
Skapa enkla, upprepbara arbetsflöden för helpdesk och admins:
Samlings dessa playbooks på ett ställe och länka dem från admin‑konsolen och interna docs.
Lägg till analys som speglar verklig inpasseringsprestanda, inte bara installationer:
Använd dessa mått för att prioritera reader‑finjusteringar och användarutbildning.
/contact)/pricing)Ett digitalt pass är det användaren ser och visar för att få åtkomst eller verifiera rättighet (badge, medlemskort, biljett, besökspass). Under ytan backas det upp av en eller flera credentials (QR‑payloads, NFC‑token) som läsarna validerar, och en livscykel (utfärda, uppdatera, suspenda, återkalla, återutfärda) som ni kan hantera operativt.
Börja med att skriva ner hela flödet (begäran → godkännande → utfärdande → passage → revision) och välj sedan mätbara mått:
Dessa mått håller "det fungerar" förankrat i verklig drift.
Använd QR när du behöver bred kompatibilitet och låga hårdvarukostnader (kameraläsare, visuella kontroller) och kan acceptera långsammare genomströmning. Använd NFC när du behöver snabba, intuitiva ”tappa för att gå in”‑upplevelser och har kompatibla läsare.
Ett vanligt, praktiskt upplägg är:
Bestäm (och dokumentera) tre saker:
Om du behöver nästan omedelbar återkallelse krävs vanligen online‑validering eller mycket frekventa readergynk.
Välj Wallet när snabb presentation och låsskärms‑tillgänglighet spelar roll (besökare, evenemang, enkla badge‑flöden). Välj in‑app när du behöver rikare arbetsflöden och starkare identitetskontroller (godkännanden, multisajt‑åtkomst, step‑up‑auth).
Många team levererar båda:
Modellera åtminstone dessa enheter:
Gör tillstånden explicita och tillåt bara avsiktliga övergångar:
pending → användaren håller på att registrera sigactive → användbarsuspended → temporärt blockeradBygg för de första fem minuterna:
Undvik statiska koder. Föredra:
Om du måste validera offline, acceptera att återkallelse inte blir i realtid och kompenserar med korta giltighetsfönster och regelbundna reader‑uppdateringar.
Välj en av tre mönster:
Sätt mål (t.ex. 300–500 ms beslutstid), definiera offline‑beteende och övervaka p95‑latens, felprocent och avvisningsorsaker per dörr/läsare.
Att separera pass från credential gör telefonbyten och credential‑rotation enklare utan att tappa identitet eller historik.
expiredrevoked → permanent ogiltigDefiniera vem som kan trigga varje transition (användare, admin, automatisk policy) och logga varje ändring med aktör, tidsstämpel och anledning.
Planera även för självbetjäning vid ny telefon och omedelbar fjärråterkallelse vid förlorad enhet.