Learn more about using OAuth 2.0 with Angular thanks to Maria Korneeva from ng-conf!
Perfect. So I'm going to share with you some of my experiences implementing Health 2.0 with Angular. My name is Maria Caneva and I work as I.T. specialist for the solutions company based in Germany. And I also write articles for injections. If you want to draw up a line, here are some contact details. But since we have a really tight schedule, I move straight forward to the agenda that would be normal again if I had an hour or two talking about this topic. But today I just want to concentrate on major takeaways from my recent project, and that's the setup. So we used to angular we had customer authorization and resource server. And since this is a single page application, we had to use code as authorization time because this is the most secure one or the recommended one. And we ended up writing our own library, but we were heavily inspired by our Thero. So that's the setup. So what are the main issues or pain points that we we were facing during the implementation for this? Let's zoom into the login flow. So pretty straightforward. The user clicks on login gets redirected by the authorization server to the login page, authenticate with identity provider and gets redirected via the redirect. You write back to the application. So far so good. But what if your application has to keep some state, for example, some input data for this? You have to encrypt your data and stored somehow securely in the browser. Or maybe you have to stored in the database, keep that ID and then pass it through the whole locking loop to get it back and then to restore the data. So it's one of the issues. What if you have multiple apps? That's all use the same login page. So then again, you have to come up with some parameters that you pass through the whole loop to the login page so that you can steer or manage its look and feel or even the choice of the identity provider. What if your app has some dynamic parameters so that the user theorise also dynamics so you cannot just stored at the authorization server without any wild cards? Sometimes login is also optional. For example, is just a nice feature allowing you to save some data if you're logged in. So how do you know if the user is and has skipped the login? So if he or she gets back, how do you prevent redirecting him or her back to the logging page or how do you handle browser back? While timeout is usually its normal scenario for any logging use case, but we figure it out, we have to deal with the HyperMED hibernate mode too. And we figured out that the Internet connection gets restored just milliseconds after the authorization request gets fired on some systems sometimes, but we had to learn it the hard way. That's why I'm sharing it with you. I'm speaking about the opposite side. So if the user keeps working your apps, you want him or her to stay locked in. So you have to refresh it. We didn't use refresh tokens because, well, for now, it's it might be secure, but it's still some use cases where it's not recommended. So we use prompt nun and session cooking as one of the recommendations. But the thing is, if your authorization server is on a different domain, then your application has to create an iFrame, attach the iFrame got the message securely and this has to be secure. Please, please, please do secure it and then attach the iFrame from the application. But if you are too quick, then some browsers, for example, Chrome might in some cases cancel your authorization request. So that's again anything that we had to learn the hard way. That's why I'm sharing with you. Multiple taps is also pretty serious. A one tap has to know if the user has locked out in the different taps. So we have to work with some event despatching. And of course, we have to deal with disabled cookies or blocked scripts. But this is just normal. That's nothing which is specific to the standard or angular. Let's look at the other side. Kipping or getting parameters of the authorization request is also necessary on the other side because the login page has to have everything to make this authorization request back to the authorization server. Speaking of code client, the redirect your write code, challenge, method, code challenge, etc. the login page has also to deal with double login, has to prevent it on the front end and all the other stuff that I've already mentioned on the application site. So as you see, this is just the first part of the whole flow, but it has a lot of interesting cases for now. I'd say I stuck here because I think my five minutes over, but I think I'm going to write an article or even series of articles or even a book of. Because so much things to tell you about the whole thing, the whole plantation experience, but for now, thank you for being here. Well, let's keep in touch.