We've set up Airflow 2.3.3 to authenticate users against Azure AD by means of OAuth-2.
So our webserver_config.py holds AUTH_TYPE = AUTH_OAUTH and an OAuth provider.
Authenticating users in Airflow's web GUI works perfectly fine.
Now we'd like to use Airflow's Rest-API (e.g. in order to schedule runs).
The official documentation is a bit unclear to me, though. It says:
Authentication for the API is handled separately to the Web Authentication. The default is to check the user session
I'd like to avoid using Basic Auth only for our API calls, but instead also use authentication via OAUTH for our API calls. So it's fine to have the API backend check the current user session.
But - how do we create this user session prior to our API calls?
Any examples for bash / cURL / python are appreciated.
Related
The rest API (https://cloud.google.com/identity-platform/docs/use-rest-api) support user sign up without request attribute, multiFactor : {enrolledFactors :[]}. It seems that the only way to enable multi-factor authentication is via NodeJS server as described here: https://cloud.google.com/identity-platform/docs/admin/manage-mfa-users.
Is this correct? NodeJS api must be relying on rest-api. So any reason, it will not work with a direct rest API call.
After further investigation, the restful API does let a client programmatically specify MFA attributes. The API is accounts.signUp.
https://cloud.google.com/identity-platform/docs/reference/rest/v1/accounts/signUp
I've created a FeathersJS backend app and a React frontend app. I'm using OAuth2 strategy to authenticate users to my own WordPress site. Everything is working fine. But now I'd like the users to be able to access my FeathersJS backend REST API, but as they authenticate through the WordPress OAuth2 server, thus following all the OAuth2 authentication process through my React frontend app, which would be the correct FeathersJS way to allow the users authenticate to my backend so that they can do REST API calls?
But now I'd like the users to be able to access my FeathersJS backend REST API
To let people access your backend REST API (which I assume is only possible after they authenticate), you need to check whether the access token they have is, in fact, valid with the third party auth provider.
You can directly let them use the back end API. In case the API doesn't find a valid access token with the incoming request, it will redirect it to the login page. After which, now the backend can validate itself with third-party OAuth provider and return the result.
following all the OAuth2 authentication process through my React frontend app
It is recommended to not do all the OAuth check from front-end since this exposes the access-token on the user agent, which might be a serious issue. See this:
https://www.digitalocean.com/community/tutorials/an-introduction-to-oauth-2#grant-type-implicit
I'm trying to implement security to a backoffice CLI tool (NodeJS) that calls a REST api (Java/JAX-RS) for performing database operations etc.
As we're using Azure AD for all our user accounts I'd like to use it for authenticating our users and also for authorization.
The authorization is needed since not all members of the AD is supposed to use the CLI, and there are two types of users of the CLI with a different set of available commands, meaning that even if you are able to use it, some features might be locked out depending if you are an operator or administrator.
I've managed to create two applications in Azure AD, one for the CLI and one for the API. I can login using our AD credentials, fetch Access tokens for the CLI app id requesting the REST API resouce. On the client side I'm using https://www.npmjs.com/package/simple-oauth2 .
On the Java side the tokens are validated against Microsoft public keys, so everything seems to work out fine.
But, how should I lock down the users to either operator or admin roles? One naive way I can think of is to have the user/role correlation in the REST API and only use the OAuth flow for authenticating the user. But I guess that's what the AD is there for... Could OAuth scopes help me in this case?
Or should the REST API call the AD to query for users group memberships, once it receives the access tokens and knows the end user identity?
Thanks in advance!
Use the Application Roles.
Here you will find good description what application roles are and how to handle them:
https://learn.microsoft.com/en-us/azure/active-directory/develop/howto-add-app-roles-in-azure-ad-apps
The recommended resources at the end and also very helpful and will guide you through the process.
Also, when developing CLI it is recommended to use the Device Flow - described here with sample code (.net core) here.
Not sure if that is possible: I would like to switch from server flow to native client flow in order to provide a better authentication experience for my users.
The problem is that Azure AppService requires a "web application" OAUTH setup (contains client ID and a secret), while the native login works with just a client ID and not secret. This means that after the login on the phone, I do have a Google token, but AppService wouldn't know what to do with it and returns me an HTTP Unauthorized.
The mobile client SDK gives me an API, but that doesn't work with such a token.
var jObject = new JObject(
new JProperty("access_token", auth.AccessToken),
new JProperty("id_token", auth.IdToken));
await ServiceClient.LoginAsync(MobileServiceAuthenticationProvider.Google, jObject);
Any idea on the proper way to integrate this without having to write my own server-side token validation?
You would still need to configure the web application in Google since you are attempting to access a non-Google API. The native login on its own is not enough.
That means you will still need to provide the backend with an ID and secret. The client is responsible for obtaining an id token and authorization code which get sent to the server, and the server does the actual retrieval of the access token, per the Google documentation.
So that means your call will actually look something like the following:
var jObject = new JObject(
new JProperty("authorization_code", auth.ServerAuthCode), // not sure what property your auth binding exposes this as
new JProperty("id_token", auth.IdToken));
await ServiceClient.LoginAsync(MobileServiceAuthenticationProvider.Google, jObject);
There isn't documentation for the end-to-end using Xamarin.Android, but you might find it useful to glance over the App Service iOS documentation for this scenario just to see the moving parts. The general pattern you will follow is:
Configure everything for the server flow (as you've done before)
Set up the Google Sign-in SDK (seems like you've done that already, too).
Make the call as described above
The main issue you might run into is making sure that you have the API console registration correct. You'll want to make sure you have an Android client there connected to the web application client ID you are using. I'd recommend giving the Google Sign-in for Android setup instructions a quick look. Also note that authorization codes are one-time use, and there are some throttles that Google puts in place for a user requesting too many of them within some span of time. You might run into that during dev.
AS far as I know, the native client flow also use the google code flow to get access token.
According to this article, the Android, iOS, or Chrome applications doesn't need the secret to get the access token.
The client secret obtained from the API Console. This value is not needed for clients registered as Android, iOS, or Chrome applications.
But the web app backend will not authorized this access token if you don't set in your backend to enable Azure App Service authentication/authorization. Because the backend will have its own logic(the mobile server library write the logic according to the access token) to return the auth token according to the access token.
Now, the most easily way to enable the client flow in your mobile app is set in your backend to enable Azure App Service google authentication/authorization with the same clientid and secret(based on my test: if you don't set the right secret, the backend will still return the auth token).
Here is the test image:
If you still don't want to enable the app google easy auth, I suggest you could create custom authentication which contains your own logic to check the accesstoekn and get the user information from the google.
If the checked result is success and get the enough value, you could generate the auth token and return to the client side.
More details about how to create custom authentication in the mobile app backend , you could refer to this article.
Here is I have a small problem of architecture, first of all, I have two applications:
An api writes symfony 3.3
A front writes too it symfony 3.3
Then, I would like have two manner to sign in:
the first one by using of third application such as Facebook, Google or Twitter. For this part I thought of using hwiOauthBundle
Or simply by login / password. Here I thought of using FOSUerbundle
Finally I would like to have secure api, that a not connected user cannot reach the resources of the api.
What do I have to install or to develop to have all the expressed criteria higher?
In advance, thank you of your answer.
You have to setup some kind of login proxy endpoint that has the oauth client_id and secret.
Then with the username and password given by the user you have to query the backend oauth token endpoint to get an accesss token.
After that you just need to sign your request to the backend with that token.
In my case I'm using FosUserBundle for user management, FosOauthServerBundle for the Open Auth management. Both are installed in the backend.
Once installed you have to register a aAuth client. This tutorial was really helpful for me OAuth2 Explained