Okta Multibranding: Choosing the Right Architecture

Hello everyone. My name is Mark Vong and I'm part of our technical marketing team here at Octa. Today we're going to dive into multibranding in the Octa customer identity platform. More specifically, multibrand architecture. For those of you who have extensive experience integrating your applications with our platform, I'm sure you've noticed that there are quite a few customization options when it comes to the octa hosted signin page. More often than not, enterprise organizations prefer to completely style brand that sign-in experience so that it meets their business um objectives. Now, it's important to understand again reiterating the point here is that the Octoin page has quite a few customization options ranging from, you know, low code using our built-in editor to highly customizable, you know, editing your CSS, HTML, maybe even attaching your own stylesheets as well. Now for specifically the multibranding requirements such as let's say for an example we have a parent company who has two subsidiaries um it's you know they desire a separate login experience for each of these companies and they want to do this in a single octa tenant. Now, in the past, we would have had to maybe consider a more custom solution like building out our own sign-in pages for each company and then using the Octa APIs behind the scenes to provide authentication. That is no longer the case today. With the current evolution of the Octa hosted signin page, we can support this use case of multibranding with many different approaches. Now, while there are multiple ways to solve this problem, the decision to go down one route over the other really depends on a few factors. Now, on our Octoin page, we as the developers have access to a variety of different contextual variables that can help us determine how to style the widget or the page itself. These contextual controls can be categorized into two different group types. The first one is the octa context. Think about the octa context as really just information that's getting pulled directly from the octa or environment and its different resources. So think about applications maybe users um etc. The first sort of subcategory within the octa context are fixed controls. So what we mean by fixed controls are you know the tenant itself the octa tenant itself the octa tenant domain these are fixed values that are associated with the org and typically don't necessarily change all that often and they can be used in an effort to help style the signin experience uh to make it cater directly to you know the specific octa or the second type is what we call a codebased context. Now, these are a little bit more dynamic. They are still coming from the octa tenant. However, in this example, you'll see we're referencing the application ID, application label. These are values that are dynamic in the sense that you know the user starts on the application, they click a login button and then they get redirected to octa. As part of that initial call to that or that request to octa, we'll have the application's contextual information. So we'll have the application ID, the label, and we can use these pieces of metadata to in an effort to style the sign-in experience uh from the octa host signin um page itself. Now the second control I want to discuss would be the external context. These are sort of outside the control of octa. Um so these controls are typically managed and provided by you know example would be the application that the user is being redirected from or maybe the user's local environment before ordering the request to octa. Now when we talk about client side storage, so let's say that the user has some sort of preference stored in the browser uh in the form of maybe a cookie or local storage. Optic can leverage this piece of information to style the widget as well and that's why you're seeing that here as part of the external context. The other option would be URL parameters. So being able to pass custom query parameters when we're making that redirect to octa from our application uh we can embed it you know as part of the query string or even in the state or not parameters um so that we can use these elements within the widget to then style um and provide specific branding according to these elements. Now, this is a dilemma when we're talking about multibranding. Um, you know, typically, again, kind of going back to that use case that I just described, you know, a company that has maybe multiple subsidiaries or child companies, they want different um, branding scenarios or different login experiences. How do we best approach this? Um, it's important for us to remember three questions and these three questions are the ones that we're going to be answering to help us determine the right path forward. So the first one is do we need single sign on or SSO across multiple brands in applications? you know, if we do need SSO across multiple brands, then maybe the approach of using, you know, um, [clears throat] multiple domains within the octa tenant is not something that we can really use. It would just simply would not suffice because we can't SSO across multiple brands um, with different top level domains. Then that would push us to the next question. What level of brand customization is needed? So for maybe a low complexity, we can use the out ofthe-box code editor within the octa UI console to provide, you know, inline conditional uh statements to, you know, render the logo, the background image, etc. However, if it's a little bit more complex, we're going to have to go ahead and say, hey, how many brands do we need to support? If it's less than we determine arbitrary number called, you know, maybe five. If it's less than five, at this point in time, we're going to have to um or we can maybe still leverage the out of the box code editor, write custom logic to be able to render um and provide different specific styling elements within the sign-in widget. However, if it's more than five, at that point in time, you know, scalability is going to be an issue. we're going to have too much code in the code editor. That's when we need to consider maybe referencing um asset files that are hosted on our own CDN or some sort of remote repository. Now with that in mind, I do want to jump to a more visual demonstration to showcase how we go through the process of you know answering these three questions to come to terms with. Okay, great. This is the path forward with what how we're going to customize our signing widget. So let's go ahead and do that. Going to go ahead and do a quick switch of gears here. Okay. Amazing. All righty. So, this is our octa tenant. As you can see, we have uh quite a few users, groups, so applications. But the most important feature for us to focus on would be customizations. Let's go ahead and hit brands. And you'll see here I've defined um three custom brands for us to take a look at. Uh we have Iron Bank, Secure Bank, and Octa. Now for the first sort of question, right? Do we need SSO across multiple brands, multiple applications? If the answer is no, then you'll see each brand can have its own custom domain or set of custom domains. So, if I were to click on Iron Bank, for example, and then go to domains, you'll see I have my own vanity URL set up here where it's login.ironbank.mbuilt.com. And if I were to actually click on this, you'll see I get redirected to a customized sign-in experience. So this is still the Octa Hosta signin page, but it's now been branded with its own background image, color scheme, and logo. And you'll see that that's reflected in theme. So I'm actually inheriting or pulling the asset files um that are stored within Opta. So this is the logo, background, and then this is my color scheme. Now if I go ahead and do the same for secure bank for example, you'll see secure bank has its own set of assets. So we have its own logo, background image and color scheme. And if we go to the domains, you'll see it has its own domain as well. Same footprint, but it's login.securebank.mbuilt.com. Secure bank with its specificity. Now if I click login.securebank.m securebank.mnb.com. You'll see it has its own styling, its own branding. It's very unique, right, to secure bank, much different than Iron Bank. And again, to reiterate, they both have different domains. So, SSO will not work and will not be effective. But that's okay because our requirement initially was no SSO needed. Now let's say we do need SSO across you know our applications our brands however we still need that multibranding experience that is completely required let's go ahead and take a look at how that could be implemented so if I were to navigate to brands and then I click on opta you'll see I still have access to um you know the default logo background image uh color schemes. I can make edits here. And if I were to click on octa.mbuild.com, it will still inherit all the necessary files. Um but you'll see this background image is a little bit different. And that is because if I go back to pages and then I hit configure. Now you'll see we have this code editor. This is where it's um we're able to provide a more custom approach to styling our octa host signin page and this goes down the path of hey the user does need SSO. Okay, great. So now we have to figure out the complexity of the implementation. Um you know do we have to support multiple brands? Maybe we have five applications. Each application needs its own, you know, dedicated signin experience with its own styling elements. Um, if it gets to that point, you'll see I do have a custom function built here within the JavaScript get client ID with the octa util object. I have a function here called get request context. This returns this object here that essentially contains all the contextual information that's relevant to this request. So I know that if I'm redirecting to the octa host sign-in widget, uh in this context, I'll have access to the application itself as well as the application's ID. And that's exactly what I'm returning in this function. I want access to the client ID or the application ID so that I can leverage it to render a specific styling element. And if I were to come down here, this is where I'm calling the method or the function. Uh I'm placing it in a client ID itself. Now if the client ID does exist just as a you know precautionary check what I'm doing is I'm getting the login background image container and I'm leveraging a switch statement here. So if it matches this specific client ID, so I know that the user's coming from this application to my Octoin page, then I'll go ahead and change the background image to an image that I've uh I've sourced from from this um from this site. And there is also the default case here as well. Now this is only a single case as I was saying previously during the presentation. You know if we have to support more than five brands at that point in time scalability will be an issue. We don't want a switch statement with way too many cases that just doesn't scale well. Um, in those instances, we'll have to look to potentially, you know, hosting our asset files externally, maybe in our own CDN in some sort of remote repository, maybe even like an S3 bucket, and then referencing them directly in uh the JavaScript within our octa hosted uh sign-in page code editor. So in those instances, we've seen customers and developers maybe reference their files to include the client ID and then just pass it forward in the file name so that they can reference it in like a head tag uh or a link within the head tag uh and so forth. So again, there's quite a bit of flexibility, but the notion is we have to really think about those three questions, right? Is it going to be um you know SSO required across multiple brands, multiple applications? Do we need a high level of complexity when it comes to styling and branding? And if we, you know, if we do, then how many brands do we need to support? Because at some point in time and the number from our perspective would probably be five. Then you know at at that point it won't really be scalable to provide five different um you know switch case statements. Um then we'll have to go the route of a little bit something a little bit more dynamic having these external again files that we can reference within the JavaScript or um the HTML itself. Now, let's take a look at what this would be or I'm sorry, what this page would look like if I were to remove the switch statement. So, let's go ahead and hit edit. All I'm going to do is comment it out. So, we can see that the original background image should now populate. So, I'm going to go ahead and close that link. open this up and you'll see great the background image was changed back. So just as a quick recap right we had multiple brands within a single octa tenant we were able to solve for that use case. If SSO was not required we can have these two separate um you know brands exist well in theory all three do exist on separate domains um but you know SSO would not work across all three here. But if that's okay, then we can go the route of um you know using quite a bit of out of the box capabilities here and leveraging the domain as sort of a separation and uh distinguishment between uh different brands. If SSO is required for multiple brands or multiple applications, then we can actually go in here, go to our code editor and leverage custom logic and application metadata or any other contextual information that we can leverage to produce some sort of logical condition so that we can provide that logical rendering here or conditional rendering if you will. Uh and this is a very high level example of what you can do. Um and also important to understand that at some point in time for us the number is five. If there are more than five brands, we'll have to really consider um you know referencing those remote asset files that are stored elsewhere externally um so that we can maintain a level of scale that will work best in our production environment. Now I do appreciate the time and if there are any questions please let us know. Our documentation does have a very very strategic uh sort of decision flow diagram that the team put together to kind of walk through the decision-m process that is very comprehensive and um I found it to be helpful personally and ultimately helped me you know sort of put this together uh in an effort to you know walk you guys through and guide us through the process. So I do appreciate the time. Thank you so much. If there are any questions, uh, you know, feel free to reach out to us. And in the meantime, keep on building. Thank you.