I'm currently working on a project where we are using OpenID Connect and Oauth2 with Keycloak's default forms.
We have requirements to implement 2FA. In an ideal world we'd scrap the keycloak forms all together and just use keycloak as a headless API and build the login forms in the main application itself.
The reasons being
We have components built in Vue.js we would like to re-use (e.g. password/code inputs, password strength indicator etc)
We don't want to maintain the same styles in two different projects
We don't want to maintain or be limited by custom templates
Don't want to write custom behaviour in vanilla js
After doing research I've found that using keycloak as an API is not recommended because the redirection between the client and 3rd party login acts as an additional layer of security, and is part of the OAuth2.0 model. We're storing users medical information so security is a concern.
What would you guys suggest?
You are right that using an OAuth server through an API is not recommended. Redirects are an important part of the security of an OAuth flow. This of course creates all the drawbacks that you mentioned - having to maintain multiple codebases with the same functionality.
A solution to this problem is to use hypermedia API with strong security mechanisms, which can be used to perform OAuth flows. Unfortunately this is not a standard yet, and it is an emerging feature. You can read how such an API works here and here you can find an in-depth description of the security features of an implementation we did at Curity.
It will definitely not be an easy task to implement it in Keycloak currently, but there most probably there is no other option to solve this problem - as you said you need 2FA, without 2FA an option is to use the Resource Owner Password Flow.
Related
We have a native Windows desktop app that uses resources that we control on behalf of our customers. In the vein of not rolling our security infrastructure I am wondering if it makes sense to use an OAuth library / framework like IdentityServer (our frontend and backend stacks are .NET based with ASP.NET Core on the backend).
But from what I have read OAuth is all about giving an application access to resources that the users owns that are managed and controlled by another party without exposing the user's security credentials to the application.
Given the application is from our point of view "trusted" it seems more straight forward for the application to capture the password directly from the user and obtain an access token (e.g. bearer token) from directly from the back end rather then redirecting the user to the web browser.
Management of authorization levels for various resources is something we need to take care of robustly, as we will have multiple applications and users which will need configurable access levels to different types of resources, so I don't really want to be rolling our own solution for this.
We also want the ability for users to remain logged for indefinite periods of time but to be able to revoke their access via a configuration change on the back end.
Should we be using a different type of framework to help ensure our implementation is sound from a security point of view? If so please any suggestions of suitable technology options would be most helpful.
Alternatively, is there a OAuth flow that makes sense in this case?
It sounds like the "Resource Owner Password Credentials Grant" might help with your problem.
In the short term, the use of oauth may not seem very different from the normally "username password + rbac" based model, but the benefits may come in terms of scalability later on, for example when single sign-on needs to be implemented, or when it comes to the need to provide service interfaces to third parties.
I am building a web app using react that calls RESTful API (built using .NET Core 3.1). The web app and soon mobile app access all data through the API. I would like to have an authentication/authorization integrated but would like to know where to start. I am thinking of IdentityServer4 to build a token service but that could be an overkill and especially security not being my speciality. But i also would like something that I can easly integrate/use but also not tied with just only one token provider (eg, MS only) - this will be too restrictive as the target users could potentially prefer to use username/password, or their google/MS/fb....). What do I do? where should I start?
I don't know the complexity of your project. Give some suggestions aobut it.
If the complexity of the project is average, you can use jwtbearer authentication and use the built-in authorization. Because you have used the front and rear separation and And authentication and authorization can be well separated according to the httpstatus.
If you do not use jwt, you can use identity. Because asp.net core has integrated identity well. But jwt is a better suggesion.
If the business you are dealing with is relatively complex, you can consider IdentityServer4. You need to configure authentication and authorization on an another server.
Well here are the moving parts, and there is quite a big learning curve, since OAuth tech covers many architectural aspects. I would aim to focus primarily on UI and API integration in the early days.
Authorization Server (AS)
This will deal with login screens, standards based messages, issuing tokens, auditing and so on. I'd recommend starting with a free or low cost cloud service, so that you can get started quickly and understand how to manage the system.
APIs
These will verify incoming access tokens and build a claims principal. I would start by understanding which claims you need and how you will authorize requests after validating the token.
Web UIs
These use Authorization Code Flow (PKCE), then handle and verify OAuth responses. A commonly used library is oidc-client, which will deal with a lot of the complexity for you.
Mobile UIs
These use the same flow above but with the use of in app browsers that handle credentials. The most commonly used library is AppAuth, which deals with the mobile plumbing.
Extensibility
Once the above parts are integrated you should then be able to do this without any code changes:
Add extra login methods, as discussed in my Federated Logins Blog Post
Switch providers once you better understand your AS requirements
Online Code Samples
My blog has a bunch of UI and API Code Samples you can run on your local PC, starting with the Initial Code Sample, then moving on to more advanced ones such as React SPA with .Net Core API.
IdentityServer4 is a good choice, not that hard to incorporate in your project. You may say it may be complicated but it simply provides an authorization API issuing authentication tokens for users requests(it provides a user and password as identity), and it gives you the option of deploying external authentication(FB,Google...). It is not an overkill as when it comes to security the more it is sophisticated the better.
here is a guide if you'r interested: https://learn.microsoft.com/en-us/aspnet/core/security/authentication/identity-api-authorization?view=aspnetcore-5.0
I have Angular 2 application which talks to the Web API and does some basic CRUD operations. I have few questions:
Is any way I can create a Login/Register page on Angular 2 using ASP.NET Identity?
How do I manipulate with a data only relates to the logged in user? (Token Based Authentication? How it works? Where to read about it?)
How can I implement login/register process on actual Angular 2 application without redirecting me to Identity Server?
I looked at IdentityServer4, OAuth2 and OpenID examples, it is a bit too complex to understand. I went thru every single step in quick start, it works but I don't understand how and what it does.
Can someone give me any resources where I can start from? Blogs, websites, books, step-by-step guides.
You're correct that at this point the most comprehensive solutions for authentication and authorization in systems that rely heavily on HTTP are based on OAuth 2.0 and OpenID Connect. This of course includes your specific scenario of a SPA calling a Web API back-end. For further read on this generic case you can check the Auth0 SPA + API Architecture Scenario or give a look at the quickstarts focused on your selected technologies:
Angular2 Quickstart
ASP.NET Core Web API Quickstart
Note: Auth0 supports OAuth 2.0/OpenID Connect so even though the docs may have additional features that are provider-specific, you may find them useful if you do indeed decide to go the OAuth 2.0/OpenID Connect route. It's one of the advantage points of relying on standards, it's easier to switch between implementation/providers.
However, you should also consider if you really need to go full OAuth 2.0/OpenID Connect as they aim to solve a lot of different use cases and as such also bring significant complexity with them. If you go that route, it's recommended that you leverage existing libraries like IdentityServer or cloud providers like Auth0, because doing your own implementation carries a lot of risk and requires significant effort.
In order to meet your requirement of providing an integrated login from within your own Angular2 front-end you could probably look into the resource owner password credentials grant specified by OAuth2.
Another alternative is doing your own custom solution, this is generally frowned upon, because it's easy to get wrong, but the theory would be:
Handle user authentication and registration (possibly using ASP .NET Identity)
Upon login exchange user credentials with some a token that you can later use to call into the API
The token could just be a random (not guessable) value used as a reference to some server-side storage that would contain information about the associated user.
I'm struggling with these concepts and having trouble finding good resources on the web.
We are looking for ways to switch out custom implementations tightly integrated into our application for standards based authentication and authorization.
Our scenario is as follows:
A simple web site (may be an app in the nearby future)
A user must log in or otherwise gain access (i.e. there's no "guest" content or other things you can do as a guest)
The site uses its own web services (REST and/or SOAP) on the backend, but it might use 3rd party web services or exposes its own services as 3rd party services for other applications
Authentication may very well be done by an external provider: Users carry a smartcard and we'd like to have one simple identity provider which reads the smartcard information and sends it back to my simple web site (so I know who the user is and what his role is for instance)
Other sites might use other methods of authentication (simple username/password for instance), so we might need a configurable Service Provider??
I'm currently looking at OAuth (2) to implement for authorizing use of our REST Services (is it also useful for SOAP?) to our web site, perhaps with a simple "Client Credentials Grant" type.
But for authentication, I'm still none the wiser. There is OpenID, but is it easy enough to build your own OpenID Identity Provider? There is Shibboleth, but it seems to have a steep learning curve for doing custom stuff. And I've looked at just building something from scratch based on the SAML Authentication Request Protocol with an HTTP Post binding. Are there any other options?
Please keep in mind that we want to be flexible with our authentication. For a certain site, we might want to do the smartcard thing, but for another maybe simple username/password login with LDAP.
If it's helpful still, I personally thought about doing it myself, then discovered a bunch of third parties. I compared (5/18/2015):
Auth0
AuthRocket
UserApp
DailyCred
Conclusion for me was Auth0, because while all the features are very similar, it felt the most legitimate, as in it's not a start-up that might disappear in a few months. Now, the reason that was super important for me was because login is a foundational requirement, so I need to believe as a customer that the Authentication as a Service will be up for as long as I will be.
Here's the full comparison story:
https://medium.com/#bsemaj/authentication-as-a-service-comparison-5-quick-lessons-for-b2b-businesses-e7587275824c
I am in the early stages of planning (in particular for the security) of a REST API through which a mobile application authenticates and then sends data to be stored in (and also to be retrieved from) the Joomla website/database. It's basically an application-to-application authentication.
I plan to use the API for own internal use which means that the otherwise important aspect of "making it easy for third party developers/API users" is not as important. My main concern is that I of course want to prevent that illicit information can be injected through such API calls. At some stage I might also be asked by external auditors about how this security aspect is properly covered - hence I better be prepared from the start... ;)
SSL is planned to be used for client/server communication and the API will also use a username/pw for authentication, But does anyone have an opinion about (and maybe experience with) using OAuth as a security layer? I do not mean using user's social media pw for the Joomla login, I mean implementing oAuth on the Joomla Component side (i.e. the Joomla side REST API).
Thanks
This is exactly what we have done at our organization. It would have been nice to follow some existing OAuth (I assume OAuth 2) implementation using Joomla but I don't think it exists other than vanilla php implementation. We used this active project but built our own from scratch. This project takes into account all Grants and I suspect if you are doing mobile app authentication like us you will stick to the Resource Owner Password Credentials Grant. So it really depends on what you are doing.
So the first part was authenticating with Joomla from our mobile app. Here is a post on the start of that. With that we followed the spec RF6749 to follow the convention needed and produced the proper Bearer Token etc.
Then it was a simple matter of doing what was needed for the mobile apps with the REST APIs.
I'm over simplifying it (especially since I'm recommending going through the RFC carefully) but once you know how to authenticate with Joomla, your sailing. IMO.