I'm testing an oauth2 authentication in Workspace with my external captive portal application.
I would like to know if the behavior is the same for Google Workspace for education? Basically the same requirements and restrictions as for Android and IOS devices
Test performed only on Google Workspace
Related
I set up a Spring Boot project using https://start.spring.io including Spring Security and Vaadin. Then I set the Vaadin version to 22.0.4 and followed this tutorial to set up a login page using Vaadin Flow and Spring Security: https://vaadin.com/docs/v22/flow/tutorial/login-and-authentication
This works perfectly and checks login attempts against an InMemoryUserDetailsManager having a dummy user. As you can see in the tutorial, this is configured in the WebSecurity class, which extends VaadinWebSecurityConfigurerAdapter.
Now, I want to authenticate against Firebase users with email address and password instead. Therefore, I set up a Firebase project and added a user. I first thought, that the login can be done using the Firebase Admin SDK, but now I think this is not possible.
How can I authenticate Firebase users with email address and password in my Spring Boot application using Vaadin Flow as a frontend framework?
Firebase has two types of SDKs:
Its regular SDKs are designed to be used in client-side, untrusted environments, such as web front-ends, Android apps, or iOS apps.
Its Admin SDKs are designed to be used in (typically server-side), trusted environments, such as your development machine, a server that you control, or Cloud Functions/Cloud Run.
Only the regular, client-side SDKs have methods to sign the user in. For the Admin SDKs this is not needed, since they already run in a trusted environment and this establish their credentials in some other way (typically through a credentials file that you download from the Firebase/Cloud console).
So there's no way to sign in to Firebase on your server-side code. This also would not make a lot of sense, because a lot of users will likely be accessing the server at once, so who is the current user?
Instead, in Firebase you typically sign the use in client-side through one of the regular SDKs, and then (if needed) you pass the ID token to the server, where your code (through an Admin SDK if available) can decode that ID token and determine what user is making the request.
You can mint your own ID token in the Admin SDK, but the flow remains the same there and you typically use this to implement a custom sign-in provider.
I have a mobile app which gets token directly from azure login. And I have a service which is using adal4j in spring boot. I cannot use the mobile generated token to authenticate spring service. Becase I use two different azure app registrations for mobile and web service. Is there a way to accomplish this ?
My understanding is that you have created 2 Enterprise Applications in Azure.
1) An Enterprise Application for your mobile app (Type: Native)
2) An Enterprise Application for your Web API app (Type: WebAPI)
For native app, you will not need a client secret but you will need a client secret for the Web API app.
Now coming to the key configurations:
In both of these, please update the manifest file to have oauth2AllowImplicitFlow set to true
Also, in your Web API Enterprise Application, please have the app id of your native app in the known client apps
"knownClientApplications": ["
Now, when calling your Web API through an end-point from the Native application, pass your token in your request header as "Authorization": "Bearer "
Also note: if you need to retrieve group claims, please update the manifest in both your enterprise apps to have the following setting for this property
"groupMembershipClaims": "SecurityGroup"
Update:
Under permissions in the native app, please add the Web API app registration to allow access
Yes, the OAuth 2.0 on-behalf-of flow should applies to your scenario. These steps constitute the On-Behalf-Of flow.
Azure AD issues a token for certain resource (which is mapped to an Azure AD app). When we call AcquireToken(), we need to provide a resourceID, only ONE resourceID. The result would have a token that can only be used for the supplied resource (id). There are ways where you could use the same token , but it is not recommended as it complicates operations logging, authentication process tracing, etc. Therefore it is better to look at the other options provided by Azure and the ADAL library. The ADAL library supports acquiring multiple access-Tokens for multiple resources using a refresh token. This means once a user is authenticated, the ADAL’s authentication context, would be able to generate an access-token to multiple resources without authenticating the user again.
Further details here.
Newbie question here on Authentication. I am used to incorporating authentication into my app backend server, like Spring Security Authentication for example. I don't really understand how the authentication providers work.
My concern is that somehow each provider can only authenticate its own accounts, ie google can only authenticate for gmail accounts, and Azure Active directory can only authenticate some kind of Microsoft registered account? I am disinclined to oauth because as a user I am always paranoid about signing in for some game or app from an unknown provider becacuse I never am sure whether I just gave my gmail or facebook account password to a rando.
I am fine giving people the option to use Oath, but less comfortable if that's the only option. I would like people to be able to give me whatever email address they want, and a password which they create for my site only.
Also these questions: If I use an authentication provider can I get the actual email address being used to log in? Or do I only get a token?
If I am going to build my own authentication service so I can accept any email domain as user name, what is the easiest to implement in Xamarin forms, and can somebody point me to a tutorial or something?
Advice appreciated thanks.
Yes, you're right, each identity provider provides the ability to authenticate their own users; Google OAuth supports Google accounts, Azure Active Directory supports Microsoft work & school accounts, Microsoft Account supports Microsoft personal accounts, and so on.
You have quite a few options on how to add support for these identity providers in your app, in addition to what we typically call 'local accounts', or accounts created specifically for the given application. I'll list out a few approaches:
You can write all the code yourself to integrate with each identity provider individually, and build-your-own local account solution as well.
You can use an SDK/library in your Xamarin Forms which facilitates using multiple identity providers within your app. The Xamarin.Auth package has historically served this purpose for Xamarin apps. It provides auth capabilities for Facebook, Google, Microsoft, and Twitter.
You can use a dedicated cloud service which provides authentication services for your app. Some examples include Azure Mobile Apps, Firebase Auth, Gigya, and more. The exact identity providers supported and the level of support for Xamarin/Xamarin Forms will vary across each one. Azure AD B2C is another option that I know supports Xamarin Forms as well as Facebook, Google, Twitter, and local accounts (disclaimer: I work on AAD B2C). These services sometimes have free tiers & paid tiers, so you can compare & contrast each.
You could also build your own authentication service using open source code like Identity Server if you wish.
It definitely depends which route you go, but generally speaking each solution will provide you access to some user profile information upon user authentication. For Azure AD B2C, you can configure the claims that are returned to your application in the tokens your app receives. For other services, you may need to make a REST API call to get some user data like the email address.
HTH.
We publish an app that use OAuth 2.0 API access on Google Apps Marketplace. It got reviewed by Google and they said our app is invalid because it shows permission screen when a user first runs the app. (The app will be removed from the Google Apps Marketplace if our app is not fixed within 30 days) To solve this issue, we have some problems.
Our app uses OpenID Connect to make users login.
Our app also uses Spreadsheet API and Calendar Resource API (OAuth 2.0 Web Application Flow)
So our questions related above is the followings:
1.
Although our app uses OpenID Connect for login, using OpenID Connect forces our app to show the permission screen. Doesn't it meet the best practice below of Google Apps Marketplace?
https://developers.google.com/apps-marketplace/practices#5_use_one-click_single_sign-on
We followed the OpenID Connect document provided by Google:
https://developers.google.com/accounts/docs/OAuth2Login
2.
Since Spreadsheet API and Calendar Resource API don't currently support the authentication method using Service Account with OAuth 2.0, we chose to use the method of Web Application Flow. Our app get the token when users login, but Google said to us that it fails to meet their SSO requirements. To solve the issue, we are thinking to change our app to authorize AFTER login within the app instead (use Web Application Flow method as it is). Does the way meet the SSO requirements? In other words, is it OK to show permission screen if after login?
We will applicate if anyone can tell us good solution to solve these problems.
Thanks,
If you register your scopes in the Google Apps Marketplace configuration screen, and then only request those scopes in the OpenID Connect flow, then the permissions screen should be automatically skipped. Please ensure the scopes match between these two locations.
Reviewing the new api (Admin SDK) Admin SDK. I found the following problem, none of these APIs have support 2 legged for the google apps marketplace, there is a way to integrate these new apis or if in the future the google apps marketplace will support for OAuth 2.0.
The Admin SDK APIs function with Two Legged OAuth just fine, I'm using the Directory API in my marketplace app today. You'll need to go into your Vendor Profile page on the marketplace, click "Register for additional APIs" and enable Admin SDK. You'll also need to add the needed API scopes to your manifest.
Also note that the google-api-python-client at least does not support OAuth 1.0 any longer so you'll need to either perform the authentication manually or utilize the old GData library to get the correct auth headers.