Envirdian

Envirdian is an environmental learning platform for schools, in production and distributed across Northern Europe through Skolon and Skolfederation. Its learners are children of roughly eight to twelve, which is the fact that sets most of the engineering. It serves Sweden, Denmark and Norway and reaches more widely across Europe, and the interface is multilingual because of it. It runs on four surfaces: a student application on mobile and on web, a dashboard where teachers run their classes, and an administration dashboard behind all of them. The learning content is organised into units and quizzes across social studies, geography, science and sustainable development, alongside an eco footprint calculator and a rewards system built to keep children coming back. The property that shapes the engineering is that identity works two ways. Where a school already has an identity platform, Envirdian federates to it and owns nothing; where a school buys a standalone licence, Envirdian owns the accounts itself. The same product has to work under both.

Teachers and students in the target ecosystem already authenticate through a school identity platform. A learning tool that stands outside that platform asks for a second login at exactly the point where adoption is decided: the start of a lesson. Integrating removes that friction but moves the identity model out of the application's control, so the platform inherits a user population and a revocation model it cannot change. Not every school has such a platform, though, so the same product also has to stand on its own accounts, and a design that assumes federation cannot sell to them. Underneath both sits the harder constraint: the user is eight. A password is a barrier before it is a security control at that age, and an interface that assumes confident reading excludes part of the class outright. Serving several countries compounds that, because a school system is a national thing: the platform inherits a different one in each market it enters. The full brief and the specific education systems involved are not documented.

A web and mobile education platform that authenticates against Skolon, the school's existing identity provider, over OAuth 2.0. A user reaching the platform is sent to Skolon for authorisation; Skolon authenticates them and returns authorisation to the application, which then establishes its own authenticated session and grants access. Where a school has no such platform, a standalone licence gives Envirdian its own accounts and its own login, and pupils enter by scanning a QR badge rather than typing a password. On top of that sit the product surfaces: units and quizzes across social studies, geography, science and sustainable development, an eco footprint calculator, and a rewards system carrying the gamification. Teachers run their own classes from a dashboard, customising the content their class sees, opening and closing units and quizzes for them, and commenting on the work that comes back. The student application is built for readers who are still learning to read, and the whole product ships in five languages.

As documented, web and mobile clients both talk to a shared backend API, and the API is the only component shown talking to Skolon, a shape that would keep one implementation of the authorisation exchange and one place where the application session is established. Two data concerns sit behind the API in the same documented shape: educational content, and users and organisations. The second is where an external identity has to be reconciled with an internal account and an internal organisation. The stack is Laravel over MySQL, with a Next.js web client and a React Native mobile app. Authentication forks before anything else does. A federated school is sent to Skolon and comes back with an assertion the API exchanges for a session; a standalone school authenticates against accounts the platform holds itself, and its pupils do so by QR. Both paths converge on the same internal user, which is what stops the fork from reaching any feature beyond sign-in. The platform runs on AWS on an Amazon EKS cluster, with Redis fronting the repeated reads, a queue carrying the work that must not sit on a request, and S3 behind CloudFront holding the lesson media. That last pair earns its place here more than it would elsewhere: a class of thirty opens the same unit in the same minute on a school network, so the bytes that matter are the ones nobody has to fetch twice. Two things stay open rather than assumed. Skolon is the only identity provider named, while the platform serves Denmark and Norway as well as Sweden and each runs its own school identity infrastructure. And the product ships in five languages, but whether the educational content itself is localised per market, as opposed to the shell around it, is a much larger question the source does not answer.

• The application never handles a password, yet still has to answer "who is this, what may they do, and are they still allowed here" from assertions issued by a system it does not control, over a network that fails, with a token that can expire mid-session.
• Multi-tenancy is not defined locally: an external school structure has to be translated into an internal tenancy boundary, which puts the organisation model downstream of a system the platform does not control. A Skolon organisation is one school, one to one, so the identity provider defines the tenant boundary rather than the platform inventing its own. That keeps the mapping trivial and puts the awkward case somewhere else entirely: schools on a standalone licence have no Skolon organisation to be defined by.
• Account linking has to be exactly-once: an external identity must resolve to one internal user on first sign-in and to the same one on every sign-in after it, across four client surfaces.
• Sign-in has a hard upstream dependency wherever a school federates: if the identity provider is unavailable, nobody at that school can enter the platform, which makes the availability of an external system a first-class property of this one.
• Two identity models in one product is the decision everything else bends around. A user created by a Skolon assertion and a user created by a standalone licence have to be the same kind of thing by the time any feature sees them, or every downstream surface grows a branch. The platform therefore owns an account model it only sometimes populates itself.
• Signing in an eight-year-old is a real design problem rather than a nicety. A QR badge replaces a password because the alternative is a teacher typing credentials for a class of thirty, and it moves the security question from something the child knows to something the child holds, which is a different threat model and a deliberate one.
• A teacher opens, closes and customises content for their own class, so content state is per-class rather than global. The same unit is available to one class, closed to another and edited for a third at the same moment, which makes the authoritative answer to what a pupil can see a function of their class rather than of the catalogue.

• Federated identity: identity, provisioning and revocation all live outside the application.
• Token lifecycle: expiry mid-session, refresh, and revocation have to be handled across four surfaces, two of them used by children.
• Account linking: mapping an external identity to an internal user, once and only once.
• Organisation mapping: translating an external school structure into internal multi-tenancy.
• Upstream dependency: if Skolon is unavailable, nobody can sign in.
• Children's data: an education context raises the obligations on everything stored, and the learners here are eight to twelve.
• Two authentication paths to maintain: federated sign-in through Skolon, and standalone accounts with QR entry for pupils.
• Accessibility as a product requirement rather than a checklist, for readers who are still learning to read.
• Multilingual delivery across the markets served, with five languages in the product.

• Skolon: school identity provider for students and teachers, integrated over OAuth 2.0
• Skolfederation: Swedish school identity federation, named as a distribution route on the product site
• Firebase Cloud Messaging: push notification delivery to the student app and to teachers

• Laravel
• MySQL
• Next.js
• React Native
• OAuth 2.0
• Redis
• Firebase Cloud Messaging
• AWS
• Amazon EKS
• Amazon S3
• Amazon CloudFront
• Docker