Decentralized identity service
We built the app-side authentication flow for a decentralized identity service that piloted a blockchain ledger in a telecom carrier's integrated account authentication. The pilot tested replacing a structure where a central server managed identity with blockchain-based verification. From the authentication request to the verification result, the app, the server, and the blockchain ledger interlock, so if one side's processing state drifts from the app screen, the user cannot tell whether authentication finished. The app was built together with another developer who took part of the features, and integration points were coordinated with the server developer.
Identity verified against a blockchain ledger instead of a central server
In a pilot that introduced a blockchain ledger into a telecom carrier's integrated account authentication, we implemented the app features linking the authentication flow to the ledger. In decentralized identity, a single company's database does not vouch for identity on its own; identity is verified against records on a tamper-resistant blockchain ledger and public-key signatures. The app-side processing was structured so the user's identity information and authentication state connect to blockchain-based verification. Before the term decentralized identity (DID) was widely used, the pilot tested verifying identity through a distributed structure instead of central management.
The steps the app shows from authentication request to verification result
In the decentralized identity app, the user requests authentication and then checks the verification result. In between, blockchain processing state and server responses were connected to app state so the user can follow the progress and outcome on screen. The decentralized identity structure, which differs from server-centred authentication, was reflected in both the screens and the logic.
Authentication data that stays verifiable through public keys and signatures
The decentralized identity app's logic was built on a public-key structure so that authentication data does not end at being sent but carries on in a verifiable state. For security-critical logic such as asymmetric keys, signatures, and authentication state checks, we applied public-key authentication experience from an earlier biometric authentication project. This app logic was designed to match the server and blockchain integration flow.
Joint coordination where the app, server, and ledger interlock
The blockchain identity service was built with a heavy server side. With the server developer, we coordinated the points where app and server meet: ledger integration, authentication requests and responses, and error-state handling. The app was co-developed with the other platform's developer, splitting features between us and aligning the specification so both platforms deliver the same authentication policy and user flow.
Highlights
A decentralized identity flow from authentication request to verification result
Integration that maps blockchain processing state and server responses to app state
Public-key and signature-based security logic with authentication state checks
Insights
GA4 client_storage: 'none'은 정말 쿠키를 막을까?
두 달 전 이 블로그에 「GA4 쿠키 없이 쓰기」라는 글을 썼습니다. clientstorage: 'none' 으로 쿠키 저장을 끄고, 자체 분석이 쓰던 익명 ID 를 clientid 로 넘기면 쿠키 0개로 GA4 를 쓸 수 있다는 내…
GA4 Measurement Protocol: gtag.js 없이 서버에서 이벤트 보내기
랜딩 페이지의 전송량을 파일 단위로 쪼개 보다가, 가장 큰 파일이 우리 코드가 아니라는 것을 알았습니다. Google Analytics 의 gtag.js 였고, 방문 한 번에 176KB 를 받고 있었습니다. 페이지 전체가 1,094K…
중소 제조업 AI 도입 순서: DX를 먼저 끝내야 할까?
공장을 가진 중소·중견 제조기업 16만여 곳 가운데 스마트공장을 도입한 곳은 19.5%입니다. 회사가 작을수록 이 비율은 더 떨어집니다. 중소벤처기업부가 2025년 4월에 낸 제1차 스마트제조혁신 실태조사 결과입니다. 그림: 기업 규…
Next.js loading.tsx와 404: 버튼이 화면보다 먼저 살아나게 하기
관리 화면 왼쪽 위에 사이드바를 접고 펴는 ☰ 버튼이 있습니다. 폭 하나 바꾸는 버튼인데, 대시보드에서 누르면 2초 넘게 아무 반응이 없었습니다. 레이아웃만 바꾸는 일이 왜 이렇게 오래 걸리는지부터 들여다봤습니다. Next.js 16…