Is it possible to connect to Keycloak an Angular 10+ spa, which gives almost the same functionality as Keycloaks Account-Console? Does anyone have experience with this?
New account console looks like "just an openid-connect"-ed reactjs webapp, i think.
Or am I better if I give up on this, and thinking in the theme functionality of account-console?
New account console is shipped also with new account API (!= admin REST API), so nothing stopping you to build own independent SPA (in your favorite platform: Angular, React, Vue, ...), which will utilize that account API.
See (random) blog post about that: https://www.marcus-povey.co.uk/2020/10/12/using-the-keycloak-accounts-management-api/
Related
I'd like to build a web app using Vue for the frontend, and Python (Flask or FastAPI) for backend API calls.
Both on the frontend and the backend, I'd like to have authentication via Okta in place.
I'm able both to create a frontend (I used Okta cli for the boilerplate) with the desired protection in place, and a backend (using Flask-OIDC). However, I'm not sure how to plug those two together: is it sufficient to protect the API calls and trust that the user will be logged in through the frontend? Do I need to protect both the frontend and the backend (I strongly believe: yes)? I'm sure there is some sort of best-practice out there, but I fail to find it; would be very grateful for any pointers in the right direction.
Thank you!
You should be fine with your approach: frontend will obtain an access_token from Okta, which you will be sending to your backend, where it should be verified appropriately.
Another architecture, which can be utilized, is establishing your own session by your backend (some sort of traditional web-client app), if you are only planning to have your front-end talking to your backend. It can be easily done with traditional authorization_code flow, where server will have both client_id and client_secret parameters. This is described in more details on Okta Developer site.
I'm not familiar with Python frameworks, so can't help with examples, but I'm sure you can find some examples online.
I am planning a small project and have a question about authentication. I would like to implement the site with Laravel 8. However, as soon as the user has successfully logged in, he should be directed to the user dashboard. The User Dashboard should be a pure VueJS Single Page Application.
Now my question. Which auth should I use here? Session or token for the whole site or is both possible and useful?
If I use the token auth variant, for example, then I can protect the Vue app very well but I cannot access the user information outside the Vue app. For example, the current profile picture of the user should appear in the navbar and not only in the vue app but also on the landing page, contact page etc.
How can I do this and what will be the best practice and thanks for your help!
Use token based Authentication
(Laravel Passport)
Use Token-based authentication system.
In this way, you'll be able to manage the entire application UI and role checking in the frontend only. I would rather prefer to go with JWT [https://jwt-auth.readthedocs.io/en/develop/laravel-installation/]. It's easy to use and the documentation is pretty good. It's even supported by Lumen also. If you wish to integrate any micro-service in your application future, then it's available in Lumen micro-service also.
Confusion about API auth types in Laravel?
I'm currently learning how to create an API in Laravel and I found myself into this confusing concepts. After a few days of research and practice, I could finally understand enough this concepts to make a mini-guide. I had to look into a lot of separate webpages so I will make my best attempt to explain the relationship between them.
What are these concepts?
Passport is an official Laravel package that implements Oauth2 and JWT.
Auth0 is an authentication and authorization service. It is kinda "all in one" solution for API auth. It implements JWT by default and can implement Oauth2 as well as many other protocols.
OAuth2 is an authorization framework or protocol that enables applications(the ones you're going to build) to
give limited access to user accounts such as Facebook, GitHub, etc... Imagine that your app grew big enough to offer a "Sign in with APP NAME HERE" or provide limited access to your users account to other third-party applications. With Oauth2 you can achieve this among many other things.
JWT is a token format. In other words, it is how data will be arranged to create a token. Another token format would be SWT.
In other words:
Passport implements -> Oauth2 and JWT.
Auth0 can implement -> Oauth2 or many other protocols like LDAP, OPEN ID, etc...
Oauth2 can implement -> JWT or other token formats like SWT...
What should you use?
Not only it would be crazy for a beginner to create its own Oauth2 implementation compatible with Laravel, but also chances are that if you're reading this is because you don't know exactly how to all the Oauth2 complexity. Oauth2 out. All we have remeaning is three package options. Passport, tymondesigns/jwt-auth and Auth0.
Before continuing, let me note that when I refer to 'JWT' or 'plain JWT' I really mean to the tymondesigns/jwt-auth package. The real match comes between Auth0, Passport and plain JWT...
Auth0 is a Swiss army knife compared to Passport and JWT. This knife is an all in one solution. It can do a lot of stuff on its own plus some extras that you might never need without depending on Laravel or other frameworks. To not extend this too long, let me just say that it can do whatever you could possibly imagine as an API beginner. Also, you would have a really good dashboard straight out of the box which will allow you to manage all aspects of your API. From third-party authentication to add more apps (mobile, web, desktop) that can consume that API.
Passport could be compared with a more delicate knife. Its creators knew what it will cut and designed it specifically for those tasks. In other words, it was built especially for Laravel to work smoothly and flawlessly without having many bells and whistles bothering around. Though, don't forget that in the long run you can implement your own code on top of it. Like a nice and custom dashboard to manage your API clients.
Finally, back to the knife analogy, I like to compare JWT with a sharpened blade without any fancy extras. It's lightweight, functional, secure and does its job. You get the benefit that you will not have to worry about all extras that the other packages add. Furthermore, you can upgrade this knife however you want due to its flexibility or even switch to another package if you need a heavier upgrade.
Conclusion
It depends on you, if you want to cut everything that might be thrown at you and stay more in the API world than in Laravel (Auth0), narrow down to the focus of Laravel and Oauth2 for third party authentications (Passport) or have a basic secure data transfer out of the box via API (JWT). And yes... You can also link your app to your mobile app with the three of them.
Personally I USED to prefer Passport because:
I like to work with the official Laravel packages.
Besides the many extra routes and tables added to my project, its performance will not be affected.
If I started with the most basic API auth and wanted to scale, it would be much easier.
The coziness of working with a Laravel Package.
Still talking about the last point, some may say that Auth0 community is small. It basically is, but also it has awesome client support personnel.
Edit: (Now I prefer Tymon JWT)
Tutorials on Passport and Oauth2
Laravel and Oauth2 Docs explanation of tokens might be a little difficult. Here is a Good Explanation of Passport's(therefore Oauth2) Different Types of Tokens and Their Use Cases. Since I couldn't figure out the "routes" part of the tutorial I wouldn't recommend the tutorial part.
This is a Good Passport Video Tutorial which also uses the PostMan Chrome app for API calls. For those of you who are new to this API stuff, apps like PostMan will make your work a lot easier than using a "curl" Linux/Mac command. You could watch the complete series or just the Passport part. At the moment I'm stuck on video 4. Here's my Stack Overflow question.
Resources
Many of the resources are all spread above in the article but I also have some here.
Stack Overflow JWT vs Oauth
Auth0 explanation of Oauth2
An Introduction to OAuth2
OAuth2 Simplified
We have a custom built web app backed by a REST API. We already have existing user accounts that are created via our system. We've just recently integrated Domo to do reporting and they recommend Okta.
Is it possible to get have users sign in on our site and in the background also sign them into Okta via an API call/OAUTH request etc?
Yes it is. The methods are available via the API, and I just created app that demos exactly this in Python. Check out http://developer.okta.com/docs/api/resources/authn.html for links to test stuff in Postman. My basic approach was to have Okta be the system of record, but it can certainly be the other way :)
We're developing an API and a single page application (that is one of more possible future consumers of it).
We already started on the web API, and basically implemented a system very similar to the one John Papa made in his course on pluralsight, named "Building Single Page Apps (SPA) with HTML5, ASP.NET Web API, Knockout and jQuery".
We now need to implement authentication and user managing in this application and need to find the easy way out to implement this in as little time as possible as we are in a hurry.
We realized the SPA template included in the ASP.NET update had very similar features to our needs, but we wonder what the best approach to implement a similar feature in our existing code.
We are novice developers, as you might figure.
Is it possible nstall some packages using the package manager, and voila, a simple membership and OAuth auth option be readily available?
Our use case is that we need to protect some resources on our API based on roles, and that one should be able to log in using a username and password, but also log in using ones facebook, google, or twitter account.
Found an interesting talk regarding the subject here: https://vimeo.com/43603474 named Dominick Baier - Securing ASP.NET Web APIs.
Synopsis: Microsoft’s new framework for writing RESTful web services and web APIs is appropriately enough called ASP.NET Web API. As the name applies, this technology is part of ASP.NET and also inherits its well-known security architecture. But in addition it also supports a number of new extensibility points and a flexible hosting infrastructure outside of IIS. There are a number of ways how to do authentication and authorization in Web API - from Windows to usernames and passwords up to token based authentication and everything in between. This talk explores the various options, and puts special focus on technologies like claims, SAML, OAuth2, Simple Web Tokens and delegation.
We eventually went with the SPA template, doing authentication on the API (separate MVC part).
Then the API would generate a unique token and redirect the user to the front-end with the token in url parameters.
The front-end then needs to send this token on every subsequent request.
Have a look here - Identity Server done by the security experts. This is all you need in one package.
In terms of OAuth, you would need to use Client-Side Web Application flow which the access token is issue immediately to the client and can be used.