I have a few applications. For each I need an authentication service, I have written this service separately. How is it possible to use this authentication service in different web applications?
The reason for separating is that I do not want to rewrite this service multiple times.
Would lerna.js be an idea to implement such a construct?
Or are there any more sensible solutions?
So you are using microservice architecture where you have written a completely separate application for authentication. This is completely fine.
Now what you would do is, deploy all the microservices and let other services to use auth server for authentication. How would you do that? Well, you can do it using our friendly RESTful architecture. Lets say you have a service X. When you try to access X, X would send a request to Auth server. Auth server will response back to the service X if you have access or not. If you have access then X service would response you back with data or authentication error.
Do you get me?
Related
I have two Azure AD applications in the same directory, let’s call them FrontendAuth and BackendAuth, which provide authentication for an ASP.NET MVC frontend and a Web API backend, respectively. The MVC frontend is protected using the standard UseOpenIdConnectAuthentication configuration, the Web API backend with UseWindowsAzureActiveDirectoryBearerAuthentication.
What I want to do is log into the frontend, authenticate against FrontendAuth, then consume via JavaScript the API hosted in the backend by providing a token, acquired using ADAL JS, to BackendAuth.
Assumptions
My expectations/assumptions are:
That I would have to configure FrontendAuth to have access to BackendAuth in the classic portal
That I would have to edit the manifest files of one or both of these to set oauth2AllowImplicitFlow to true
That when I configure ADAL JS I should be setting clientId to be that of FrontendAuth
The endpoints object of the ADAL JS configuration should contain the Url of the backend API and the client ID of BackendAuth
Outcome
I can achieve my goal of logging in to the frontend and communicating with the backend service via ADAL JS with:
The FrontendAuth application having no access to BackendAuth at all
Neither manifest file having the oauth2AllowImplicitFlow property set to true
ADAL JS having the clientId set to be that of BackendAuth
The endpoints object of the ADAL JS configuration not set at all
Questions
Based on these findings I would like to understand the following:
Were my assumptions correct? Is this how ADAL JS is intended to work?
Why did the lack of application access and unchanged manifest files have no effect on whether the authentication succeeded?
When do these measures have an effect on the authentication outcome?
You are mixing up two OAuth2 flows here (authorization code flow and implicit flow). Both are meant to issue a token to a client application. The auth code flow is used for web apps running on the server (like your MVC app) and the implicit flow is meant for public clients like a SPA.
When you use OpenID Connect to sign in your user to your MVC application, using the hybrid flow, you receive an authorization code from the browser. You use this code to talk to the authorization server and get a JWT token which is then stored in a cookie session. You can use the same code to get a JWT token for your BackendAuth app, as long as you have given permission to your FrontendAuth app to call the BackendAuth app.
If you want to enable the JavaScript in the user's browser to call into the BackendAuth app, you'll need to somehow pass the access token to the browser. You can do this by sending the token along with the initial request and put it in local storage or expose a (secured) MVC route to get the token.
For an example of what I'm describing here see this Azure AD sample, which acquires a token for the Graph API using the authorization code is received.
ADAL.js implements the implicit flow and is meant for JavaScript applications like SPAs etc.
It sounds like you haven't explicitly decorated your Web API controllers with [Authorize] attributes (either at the class level, or the action level). Thus, your Web API may be happy to serve content to anyone who requests it.
I have a database with API written in Python (Flask). I want to build a frontend which makes requests to API and display data. But I want to control the access to the API.
I couldn't implement authorization because my web app is a public client type (according to Oauth RFC) -- so there is no way to store credentials securely to authenticate the app. And I don't need user authentication (the web app is a simple catalog with interactive filters and cart).
So I need somehow to protect JS-code (uglifying/obfuscating is not enough, because I have ajax requests with URIs) or rebuild the whole web app in some way to hide ajax requests and secure the API.
Does anybody has any ideas and hints how is it possible to secure API + frontend web-app without user authentication?
It should be trivial because there're a lot of products catalogs which work in interactive manner like tesco and its filtering mechanism. But I don't understand how.
Could you give a hint?
The previous question REST API: user-agent-based client (app) authorization
I would to ask a few questions to better understand some procedures. I'm trying to write a web api project which will be a backend for both web and mobile clients.
The problem that i've in mind is about security. I don't want to use Identity or any other providers. I want to use my own database user and role structures.
Only authenticated client applications should be consuming my application. So that anonymous applications should not consume it.
So what should be the approach ? I 've written a custom AuthorizationAttribute and check some custom headers like "AppID","AppSecurity" key which i store in my own database and if the client sends the right appId and the key it means the app is authenticated to consume the API which does not sound very secure to me.
Another issue is that ; Lets say i've developed a javascript web application and i've to first authenticate the application itself before making GET/POST/PUT/DELETE etc requests which means i've to add some kind of authentication data like username, appkey, password in one of the js files for sending the "AppID" and the "AppSecurity" keys in the header. A client who knows how to use some developer tools or fiddler can easily capture my header values that are being sent to the server side? Even if i pass authentication values on the body of my json request it still can be found on the js files that are sent to the client. I'm also confused about that tooç
So basically i want to build a server side api that will serve the data and get data from the authenticated client applications only. What i need is a simple example for that without using any identity providers.
I am building an API and had questions about handling authentication when using a front-end framework such as Backbone.js.
I have a single API server that is responsible for returning and modifying data based on RESTful web requests.
I have another app server that is a Backbone application. I want this application to connect directly with my API server, so set the entire project up so that this app server can make cross-domain AJAX requests to the API server.
There are some API routes that I do not want unauthorized parties to obtain access to. For example, I have a path /users that lists all the users of my app. I need this path later on for admin functions, but I don't want it publicly available to my app server.
What is a good authentication scheme to use? OAuth won't work because the secret token would be exposed on the front-end. And after that, I'm a little stuck with what my options are. Does anyone have any suggestions moving forward?
In cases like these I use a combination of techniques.
-- Good ole Cookie based auth
As a backbone app will always be used inside a browser and browsers have built-in cookie support, I would suggest that you should accept cookie based sessions on the server side. All the auth related stuff will be handled by the browser and you don't have to worry about storing keys etc. On top many libraries like (NSURL in iPhone) and frameworks (like PhoneGap/Trigger) all support cookies so woha you can support all kind of clients with litte work.
-- Plain API Key
For third-parties, I use api-key based authentication. You provide username and password, I provide key. You send me that key every time in HTTP header for all subsequent requests. I use the key to identify you and then allow/disallow actions accordingly.
I assume once you can authenticate a user (wait..who are you?), then you can setup authorizations ( you say Micheal ? ...ok you can access /users )
Also take a look at my backbone-parse plugin for an idea on how to authenticate users against an external API service #shamelessplug
I have a WCF application where I make JavaScript calls to. I want to secure the web services so you have to be logged in to use it. This is easy if I have a server-side application making the requests to the WCF. If I am using a pure JavaScript / jQuery client-side app, I can authenticate fine by passing the credentials as JSON parameter, but how do I keep that client-side app logged in from that point on? Do I store a cookie? I do not want to store the credentials in the cookie of course because that is not secure. So how can I achieve this without introducing another server-side application to the mix? How do web apps achieve this?
OAuth is kind of the go to solution for JS API's. Netflix, Yelp, Facebook etc. use this.
Here is an article on OAuth in WCF
And here is a pretty well known library for doing auth in .NET: DotNetOpenAuth
If you use or are using ASP.Net form authentication (WCF should be running in ASP.Net compatibility mode) then there is not much to do.
If you set the form authentication ticket\cookie after your initial authentication, the cookie would be attached to every subsequent request from the browser without you writing any code. All future calls to WCF service then can be authenticated on the server using the standard ASP.Net authentication pipeline.