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.
Related
I've been searching for a solution that makes sense for the past few days, so forgive me if I overlooked something or am ignorant to the correct path.
I have an existing Website built with asp.net framework MVC where users register for Individual Accounts and are stored in a MSSQL Database. I'm creating a Xamarin.Forms app where we want users to login with their website credentials.
I've been looking at Microsoft docs to try and accomplish this. In the past I created an Apache Cordova app (2014) that communicated in a similar fashion successfully (potentially in an insecure way) that called the /Token endpoint and Authenticated the user with 'grant_password' flow and returned the user data to the app.
So I landed on this documentation: https://learn.microsoft.com/en-us/azure/active-directory/develop/v2-oauth-ropc
However, from what I can gather it basically says this should be avoided moving forward and a MSAL approach should be used if possible.
After reading through hours and hours of documentation trying to make sense of it all, I can't seem to grasp what my options are. It seems to me that in any MSAL flow, users will have to login with Microsoft accounts or other social accounts (facebook, google).
Am I missing something?
Am I going to have to go against Microsoft's advice and end up storing the client_id and client_secret within the Xamarin app source code? Which from everything I've read is a big security concern, especially with Android apps.
References: 1. Restrict API requests to only my own mobile app 2. How to secure an API REST for mobile app? (if sniffing requests gives you the "key")
Any help or direction would be really appreciated. Thank you
Your focus should be on requirements + understanding preferred designs rather than jumping to a technology.
DIRECTION
Standard modern systems look like this:
Mobile apps use OpenID Connect to sign users in
Authorization Server issues access tokens to the mobile app
APIs authorize requests via JWTs containing scopes and claims
Aim to make iterative steps towards this type of architecture.
PATTERNS
Plug in an Authorization Server, which uses your existing database as a credential store
Mobile app uses AppAuth Libraries to sign users in and receives access tokens
Back end can handle JWTs without data security risks
DIFFICULT AREAS
Your existing back end may have no support for mobile clients, and be too web focused - eg requiring cookies to access data, so may need to be split in be into 2 entry points.
Choosing an Authorization Server (while you are learning) is difficult, because you may not know what you want yet.
The mobile app will spin up the system browser and present a login page from the Authorization Server, so the login UX could be unexpected.
STEP 1
Ensure that you can authenticate from the mobile app, then make API calls with JWTs and ensure that requests for data are properly authorized. This could use ropc and involve a temporary API. But the deliverable should be that your back end now supports calls from mobile apps.
STEP 2
Integrate AppAuth into the mobile app, which is tricky but there are resources online such as Curity Mobile Guides. Update the mobile app to use the Code Flow and integrate an Authorization Server, then deal with connecting to credential stores.
SUMMARY
This stuff is hard and reflects the cost of modernising architectures. It requires people agreement as well as the technical stuff. Happy to answer follow up questions if it helps.
We have a web application with Rich Client Architecture.
We use React for our client side and Java/Spring for our back-end.
Now the question is should login page be a part of our react program or not?
As I know, if we do so, the downsides are:
The UI is not protected and everyone, even those without any access, can download the whole UI app.
Everyone, even without access must download the whole UI application before logging in.
And the upsides are:
The page need not to be refreshed when someone logeed in.
Front-end and back-end parts can be totally separated without any shared sessions.
In most known apps such as gmail, slack, etc. the rich client app (angular, react, etc.) is just after logging in and I just don't know any application with the first approach.
Frontend is generally not protected. There are potential ways to make it harder to brake code, but it will be always possible.
Because of 1 -> you should not keep any sensitive data in frontend.
As an secured way of transfering data from Spring backend to React(or any other like Angular,VueJS etc) you should probably use JWT or OAuth2.
You can decode your JWT on frontend (but only backend can verify if it is valid token so don't worry) to get encoded scopes,roles etc to use them e.g. to show admin only options.
To answer your question - login page definitely can be part of React app, as it will send login credentials and get back JWT from backend
When user is logged in - you will attach JWT in headers with every request, so your Spring Security can check it and authorize request.
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 :)
I am building a mobile app in which the users need to be authenticated via TrueVault which is a HIPAA compliant data store. TrueVault offers a REST API and generate an access token post basic authentication. They have endpoints to check token validity etc too.
We need to do 2 things:
1) Authenticate all users via TrueVault and store the auto generated TrueVault id in Parse to facilitate data mapping.
2) Setup an interceptor in Parse which verifies the access token with TrueVault before serving any protected resource.
What would be the simplest and most efficient way to implement the above? I have gone through the tutorial to add Third Party oAuth to the mobile apps, but TrueVault does not have oAuth in place yet and thus needs authorization requests via Basic Auth only. Also, would we need Cloud Code for the above or Custom Web Hooks?
Thanks
Sameer
i would suggest you to use retrofit, Gson(or jackson) and rxjava(rxAndroid) in order to handle all api calls, i made a quick overview to the api documentation and this libraries should work for this problem.
links:
https://github.com/square/retrofit
https://code.google.com/p/google-gson/
https://github.com/ReactiveX/RxAndroid
Cheers.
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.