Future-Ready CIAM in Practice: Turning Security and UX into Shared Guardrails in a Multi-Brand Environment

Hi everybody, thanks for your patience for us. So, a warm welcome from both of us first. My name is Sebastian, I'm from congstar, and this is Bastian from BareID, so the mind of our journey. And in this session, we will walk you through our journey to congstar's SSO solution.

So, how we turned security and user experience into shared guardrails. How we rolled them out across all brands and touchpoints. And what we learned along the way.

So, I really hope that you will take some insights away here. So, let's proceed. Thank you. To quickly introduce ourselves. I'm Bastian, working with BareID. We support congstar for more than two years already with a single-sign-on and CIAM solution. Which basically covers all the authentication parts end-users and customers will have when they log in to their apps, web and mobile.

Yeah, thanks. So, congstar is a team of about 300 people.

So, with Deutsche Telekom at the back and congstar at our heart, we deliver fair mobile and fixed internet services. So, at congstar, we stand for fairness and diversity. Our mission is, we boldly keep setting new standards.

So, simple, fair, digital and sustainable. And my part is just to be accountable of the SSO solution.

So, I'm a product owner with a great team and I'm proud to be the PO of the product. So, let's talk about congstar's environment. We are in need of one SSO solution for all web platforms and apps.

So, congstar operates across four brands for more than 7 million customers. And this year, we will reach 8 million.

So, congstar is the core brand. We call it Black Label. And there are several white labels.

So, the biggest one is Frank. And the two other partner brands from Rewe are Yamobile and Pennymobile.

So, each brand has its own dedicated app. And in addition to that, we have a web login.

So, the SSO solution has to cover everything. So, in this environment, we face multiple and often competing challenges.

So, I'm sure you are aware of all these challenges. We at congstar had to bring all these together into one scalable SSO solution.

So, let's talk about three highlights or let's say hard challenges. So, the first is fraud. Two years ago, we identified a high fraud risk potential.

So, especially due to missing MFA. And we knew we had to act, especially our customer finance team.

So, and the other thing is, well, the login should be easy, right? So, our previous login was password-based. Introducing MFA was essential. But it also had to remain simple. And therefore, we had to reach a good priority in our company.

So, business priority was the driver. And priority means that leadership team has to listen, has to understand or try to understand. And they have to provide a clear guidance.

So, our leadership team followed our recommendation and gave a clear guidance. That was quite good. But in the end, it was also quite heavy expectations, right?

So, our learning was, in a nutshell, SSO ownership was the answer. A simple idea, right? With big impact. What does it mean? It means taking full responsibility for the entire login experience. Not just the login itself. In the past, the login was treated as an enabling service.

Now, it's a user-facing product. As the SSO team, we have to understand all stakeholders and, of course, our customers. We had to align all of these perspectives and turn them into a shared solution. But the development team is not able to deliver everything, right?

So, we are part of a big family. So, we built one cross-functional team with the SSO Scrum team in the lead.

So, bringing all stakeholders together was the key. In today's world, especially in times of AI, code delivery is no longer the bottleneck.

So, the new challenge is the alignment before and after the code delivery. Still, we work as one team with one shared goal. Our new login experience.

Same, same, but different. Lasti, so please proceed with the journey. Thank you. Two years ago, when Kongster started to evaluate on an IDP solution or SSO solution, there were some hard reasons not to go with a vendor that has a closed ecosystem. With all the openness in Kongster, it was important to have a solution that is built upon open-source software, server-side solutions.

So, the solution that will be put in place can be managed and can be used over the next decade or so. After deciding, we quickly started to two important points. First of all, we started to prepare the existing infrastructure.

Of course, there were already authentication systems in place. They were already in lock-in. There were apps with the sessions. People hate getting locked out.

So, we started one stream, which was preparing the existing infrastructure to issue tokens and sessions and information to the apps that even after migrating to the new identity provider and the new SSO solution, users will not be locked out. Users will simply continue using the app without ever noticing that we changed the whole backend. The other big topic was integrating with the existing Kongster infrastructure.

Of course, Kongster did not start in 2024. There is a huge backend. There are huge systems handling all the customer life cycles and so on.

So, we had to integrate there with the team. Going forward, at some point, we started the shadow launch. The idea was to ensure that the new system will behave exactly like the old systems. That means we launched the new identity provider and SSO provider, basically redirecting all traffic and all incoming requests to both systems and monitoring their behavior to ensure the new system behaves in the same way as the old system. That made us confident to switch on the new IDP, turn off the old one, and then simply let the users use the new identity providers.

In the backend, this was a huge change because all backend systems, applications, and so on were speaking to the new identity provider. And you know that from migration projects, no two systems are the same. But this worked very, very well. Users did not notice. We managed to migrate about 95% of the user sessions without anyone noticing.

Then, going forward and getting more out of the new identity provider, beginning of 2025, we started to enforce the new identity provider on apps. That essentially means forced updates to all the applications to use new identity and authentication flow. Because this was when we were able to enforce mandatory multi-factor authentication to more and more fight the fraud situation. But after all, the biggest win was to launch PathKeys after we set up the new authentication provider.

So, how did we integrate with the Kongstar platforms? As Sebastian already said, there are multiple brands, there are multiple entry points where people start their authentication journey. Such authentication is key because it will be the very first thing a new customer or an existing customer will face when they open their app. There is no welcome page, there is a login page. People need to be able to log in and authenticate. And they need to be able to log in using, be it a PathKey, user number, username, customer number, all these different information.

It is of no use to replace or to duplicate existing passwords, existing authentication. All has to work flawless.

So, when the user logs in, they come to the BearID-based Kiklog solution, interface with the backend Kongstar infrastructure, which then essentially ends up in the user identity. There is information to which tenant the user belongs. There is information on that customer.

So, backend systems know what is actually going on, how the systems interact, what data is available and who the user is. On the same time, we create all these signals, all the information to provide better information about KPIs, audit trails, Xeom integrations, events.

So, the whole fraud teams, the business side, they can all evaluate what is actually going on. Are our customers using the authentication platform? If the customer agents, the support people are able to authenticate users and to support users. Migrating those users, I already said that was key, because one of the worst things that happens for regular users is getting locked out. Users expect to log in once and then be locked in for a very, very long time. This has two important things we need to keep in mind. One is consistent re-authentication. Has the account changed? Was the account blocked?

Whatever. So, to provide the old authentication system with a way that the new authentication system can take over, we started to issue so-called forward compatible tokens. Essentially, it's just some cryptography we did in the backend, that the old system and the new old system spoke the very same language. That allowed us, when we turned on the new identity provider, to seamlessly migrate all the sessions, all the locked-in users, which was about 95% of all users, which is quite a good number, I think, even when there are users who only log in once a year.

And then, of course, now the new IDP took over. The other... Sorry.

Thanks, Basti. So, let's start with screenshots, right?

So, in our legacy system, authentication was based on a password. So, our first approach was clear. We have to enforce MFA by default.

So, this made the OTP-based lock-in mandatory for all users. So, a hard decision, but a straight decision. From a security perspective, it worked. Fraud dropped significantly. At the same time, we created a new problem. The user experience was far from ideal. Some might say it was pain in the ass. Customers had to switch to email and SMS. The overall process became frustrating, even though we fixed many edge cases within days. But this didn't fix the whole process. And we didn't just see that in metrics. We saw it in customer service as well.

So, the answer, you already know. Passkeys become our solution to both challenges. Fraud and easy lock-in. Passkeys are secure and highly accepted by users. Let's talk about the security, Basti. The main difference between passkeys and passwords is that there is a cryptographic solution which is built into the devices on the one hand.

And then, using public and private cryptography, it's stored on the server. That has two huge advantages.

One is, it is natively implemented in the end-user's device. And on the other hand, there is no password hash that could be stolen in case of a data breach.

So, it has a huge advantage for all the users. Also, as most operating systems support it these days, the acceptance for the users is very high because users are used to their face ID, touch ID, and so on, authentication processes. When we decided to roll out passkeys, we also thought about rolling it only for a small amount of people. Earlier today, eBay did these. But we actually decided when the day came for launching passkeys to just enable passkeys for every user. Every user does not mean we locked out every user and forced people to sign up with passkeys.

But instead, users who had to log in again could use the existing flow with username, password, multifactor, OTP. And then they were asked, hey, do you want to set up passkeys? And I remember the day we turned it on. We had so many new passkey registrations that we actually thought the system is broken and is creating random passkeys all the time because we did not expect that the users were just accepting the feature right out of the box. The user experience was just, I click one more time the next time I need to log in because that happens every six months or so.

And the next time they use their app or the web or whatever, they just use a fingerprint or they smile using face ID. So, the number of new passkeys signups with the exemption of New Year's evening was steady. And they're steady. Most users who need to log in are upgrading their account to use passkeys and the acceptance is awesome.

So, what would we tell ourselves starting such a project again? One important thing is we do not want to, we do not see SSO as a project which needs to be started, implemented and done. It becomes part of the product and needs to be owned by the product and the product team to provide continuous service, continuous integration, continuous improvements over the next years.

So, and know your enemy, know your fraud potential, right? So, I really can say, take care of it and address the need of MFA in your company. When we talk about authentication and security, we are all very tech-savvy people. We all know how to log in somewhere. People who are unable to use phones or devices in a way we use because they might need assisting software, they need accessibility support. They all need to be thought here. These solutions, these authentication and user experience needs to work for everyone. We do not want to build a solution for techy people.

We want to build a solution for everyone. Okay, so let's talk about make or buy decisions.

So, in our case, building everything limited our ability to scale. By choosing a buy solution with our partner Berdy, we didn't lose ownership. We actually elevated it. Ownership is not about building everything yourself. It's about owning the outcome, the experience, and the impact. The architecture, especially in the multi-branded identity environment, is key. As we put that at one of the very first topics and priorities for us, we are able to let all the users stay logged in, stay in their apps, in their environment, without most people ever noticing. Sometimes it's simple.

Customers love PaaSkies. So, customers love PaaSkies. We see it across all labels and levels. From our data to direct customer feedback, adoption continues to grow. And we are not done yet.

So, maybe with a session right now. But not with our project. Product. Forget project. The next challenges are already ahead of us. And with what we've built, our SSO platform is ready for the future. I hope the same for you.

So, thanks a lot. Thanks for your attention. And have a quite good day. Thank you very much. Thank you very much, Basia and Sebastian. And as I learned, as a private person for sure, I'm also Kongster customer indirectly. Best decision. Thanks.

So, first learning today. Very interesting point. Both of you mentioned that the adoption rate was pretty fast. I remember eBay had a very slow start. Any ideas why for you it worked that fast? Why we customers use PaaSkies? I think even though we built a solution to roll it out only to a certain percentage of certain user groups, we just decided to roll it out for everyone. Because we decided the advantage for everyone is so high, let's just give people the chance to use it. And people had the option, people opted in, they used it and they were happy. Maybe just that simple. Also an answer.

So, again, thank you very much. Thanks a lot.