-
Notifications
You must be signed in to change notification settings - Fork 529
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Integration with .NET Identity #2225
Comments
I have also tried the following:
With the above, I am able to signin to my Identity db using GoogleOpenIdConnect as an external login. My theory is that setting Also tried to follow the Sample code, which has a method in the HomeController to retrieve the tokens:
|
I'm looking at this, I'll reply here as soon as I know more. I'm hoping I have some more info today. |
I have been faced with the exact same issues as @fracampit and have not been able to find a solution I would like to chime in and state as that it would be awesome if we could store the refresh token returned as part of the user data in the database. This way the backend system could use the refresh token for automated tasks. I have also been fighting with this exact same issue for months and have not been able to solve it. |
In case it helps, this is very close but uses |
I've been looking at this most of today. I'm pretty sure I tested something very similar to what's described in the SO question and it didn't fully worked. I'll check my notes tomorrow and retest if necessary. |
I've made some advances in understanding what's happening, but I'm not fully there yet. |
Quick update: I didn't have time to look into this again this week, nor will I be able to do so next week. |
@amanda-tarafa Have you had a chance to get back on this? |
I was wondering the something last week. I'm really excited to see this working. |
No, I'm sorry, a couple higher priority issues have come my way, and this one has unfortunately dropped on the priority list. For expectations: I would have though that this should work out of the box, and it doesn't. I understand why it doesn't but I haven't figured out how to work around it. I'm hoping it's a matter of configuration or slight code twaeking, but I might be wrong. I'll be able to dedicate one day to this issue, possibly next week, but not much more than that at the moment. If my hopes are met, and the fix is small, I'll bring it to conclusion, but else, we'll treat this as a low priority feature request and add it to our normal planning cycle etc. I'm conscious this is not what you wanted to hear, and I'm sorry about that. And hopefully, I can get it to work easily. |
Im a little confused as to how this could be a low priority feature request. Asp .net support is on the list of supported frameworks. So its defiantly not a feature request, if its something that's supported. As has been shown in this thread Microsoft identity and the Google apis .net client authorization mechanisms area not compatible. For some reason this library has added identity into the mix when it should be purely authorization. Not user authencation. IMO this is a major bug in this library that by authorizing a user. You also log them out of the application itself. I have had serval clients over they last two years who are using standard Microsoft identity and trying to add the use of Oauth2 to a Google api using this library. In both instances I had to drop this library completely and create it from scratch. Which basically means this library is not usable for Asp .Net and maybe that should be removed from supported frameworks and add it to the list of authorization frameworks we do not support. Unity, Xamarin ... This library has always been an authorization library as it should be.
I still have not even figured out how to get the refresh token out of the cookie properly after authorization for storage.. |
Supporting ASP.NET Core does not imply supporting ASP.NET Identity, and we don't claim to or was this ever a requisite for Google.Apis.Auth.AspNetCore or Google.Apis.Auth.AspNetCore3. In general, and across the many libraries, we don't support each API or specific framework defined by .NET or by ASP.NET, and definetely we don't intent to support them all. As an example of this, we only recently added some .NET DI support to the gRPC libraries in https://github.com/googleapis/google-cloud-dotnet.
Not sure what you mean here, surely there cannot be authorization without authentication. Say, even if some users were to use something else for authentication (like ASP.NET Identity), and we could hop into that for all cases, we wouldn't want to force all users to always need extra dependencies for authentication. The Google.Apis.Auth.AspNetCore packages are desgined to be used on their own.
It's not a bug, it's the sympton of the suspected imcompatibility. But again, being compatible with ASP.NET Identity has never been a requisite of the Google.Apis.Auth.AspNetCore packages.
No, the suspected incompatibility is between Google.Apis.Auth.AspNetCore packages and ASP.NET Identity, not with ASP.NET Core. Supporting ASP.NET Core does not imply supporting ASP.NET Identity.
We can hardly do that, as we cannot perform authorization without authentication.
If by clobbering you mean overwriting or reusing, we are not. That's precisely why my initial inclination was that this should work out of the box. What's happening is that only one of the two cookies is ever saved, depending on who's configured to do what, and I still don't understand why or how to work around it.
See here for how to obtain the refresh token every time it is issued: #1725 (comment) All of the above said, the ideal outcome for us is that we can make the Google.Apis.Auth.AspNetCore packages fully supportive of ASP.NET Identity, while maintaining their capacity of being used on their own and without introducing any breaking changes. I still hope that can be achieved through configuration or even maybe some minor code tweaking. If that's the case, then we'll get this sorted before end of year (potentially sooner). But if for making the packages compatible we need to make significant code changes, or even, if we need to produce entirely new packages (which is a posibility), then this feature request will go into our normal planning cycle and likely with a medium to low priority. I appreciate this is not what you want to hear, but it is the reality, and I'd prefer expectations to be reasonable, rather than have dissapointments later. I'll come back to this thread with an update once I've had the chance to put some time into it, I'm planning that to be early next week. |
Quick update: I've made some advances yesterday, but not quite there yet. I'll come back to this issue later this week or early the next for a last "quick" attempt at getting things to work. Else, we'll plan to look into this as a feature request for next year. |
Quick update: I haven't been able to come back to this issue. I'll do my best to come back to this next week, and I'll report back. |
@amanda-tarafa Thanks for keeping this under your radar. Any help is much appreciated. |
@fracampit Thank you for your patietence. |
I have found only one methodology for simultaneously working with this library and Identity in an ASP.NET Core 7 project. After multiple failed strategies, conflicting cookies and authentication loops, this seems to be the least "hackish" way to achieve integration:
Less than ideal -- but from a user perspective, this results in expected OAuth behaviour. The complexity of ASP.NET Identity makes the current state of affairs understandable in a library that is ultimately in maintenance mode. Devs will require a better supported option in the future from Google for ASP.NET core. Google is obviously aware of this since their previous C# tutorials now redirect to Javascript, and C# is no longer listed as one of the supported languages. |
@jboiss where you able to add additional scopes without using GoogleScopedAuthorize? |
@LindaLawton Yes, by passing the refresh token stored in the AspNetUserTokens table to the
|
After a few more hours attempting to make Google.Apis.Auth.AspNetCore3 with .NET Indentity seamlessly, I haven't been able to.
I'll come back to this thread as I know more. |
@jboiss I did wanted to ask you about this:
Can you please share the previous C# tutorials URLs (the ones that now redirect to Javascript) and also where is it that C# is no longer listed as one of the supported languages? Thanks! |
@amanda-tarafa No problem. The previous guide can be viewed at the Web Archive which now redirects to the Javascript Quickstart. On the left hand navigation there is no longer a link to C# examples (which was previously listed as .NET between Java and Node.js menu items.) In the guide to server side apps, .NET is listed on the left hand menu, but is absent from the language tabs in the documentation body, which includes examples for PHP, Python, Ruby, Node.js and HTTP/REST. |
@jboiss the calendar example uses All of the Google samples and i mean all even node.js php and phyton they all use installed app samples none of the official QuickStart's have ever been web related except maybe JavaScript and even a few of them used to tell you to create installed credentials. The only docs we have for this library with web is -> web-applications-asp.net-core-3 @amanda-tarafa i'm sad to hear of your conclusion but it is the same conclusion that i came to about three years ago. So if anything it makes me feel better that i wasn't wrong. I would love to see an overhaul of the auth system in this library to enable things like Xamarin, Maui, UWP, web. Its strange that we would only support installed apps, and service accounts. May i suggest editing the readme to reelect that Web is not supported. |
@jboiss A few notes on those links and overall C# support across Google.
The missing quickstart is specifically for the Google.Apis.Calendar.v3 library. The authentication/authorization code there is still very much supported and I can guarantee you that it will work, 100%. The whole quickstart is demonstrating client side applications, which couldn't make (meaningful) use of Google.Apis.Auth.AspNetCore3 or ASP.NET Core Identity. It's really unrelated to this issue. I don't know why the quickstart was removed, I'll follow up with the Calendar team. But again, the auth code there is still very much supported. The documentation for many other Google products includes samples, quickstarts and tutorials for C#. Here KMS as one random example: https://cloud.google.com/kms/docs/reference/libraries.
There are also no examples for Java and Go. This is a bug in the documentation, but I can also guarantee 100% that these three languages (C#, Java and Go) are very well supported for server-side OAuth. So in general:
Some relevant documentation:
|
@amanda-tarafa if you start doing to much documentation you will put me out of a job. Dont worry about it. Remember I take requests if you get flooded with requests for something special let me know. I am happy to write them for you. |
@amanda-tarafa Understood, thank you for your efforts. I was able to piece together what I needed thanks to Google documentation from various libraries. Since this library is in maintenance mode according to the Github Readme and ASP.NET Core has been somewhat of a moving target, I figured that a new solution was probably in the works. @LindaLawton I was trying to demonstrate how I added a scope for a service without conflict -- in this case, the Google Calendar API. |
Thanks for the clarification, I saw the change on the developers site that the admin-sdk got renamed to admin console taking most of the code samples down with C# and nearly had a heart attack. Looking forward to any updates on this identity integration. |
Its been a while now and just wondering if there is any progress in this regard. Really looking forward to have this supported. I defintely dont want to write anything from scratch like @LindaLawton had to. If its slotted for the near future, I would rather wait. @amanda-tarafa if you have any clarity on timeframe? |
@sagarvadodaria we still don't have clarity on timeframe. And to be upfront it is unlikely that we'll have that clarity this semester. This is not forgotten, and something that we very much want to support, but it's not high on our priorities at the moment. I understand this is not what you want to hear. |
I understand, thanks for your prompt response. |
Its been almost a year thought we should loop back and check the status on this. |
Still in our backlog, but with no planned ETA. I'm sorry this is not what you want to hear, but it's the reality given other work that we are doing, and resource constraints etc. |
Thats fine no worries think I have been waiting for this for going on six or seven years. there are work arounds. |
I finally came back to this problem after about two years and, with the help of AI, I was able to put together something that works. For context, I'm working on a .NET 8 Razor Pages website. I am using Microsoft.Identity with AWS DynamoDB. In my
I then created a controller to handle the authentication to YouTube:
This controller is used to link the YouTube account, and to upload videos to YouTube (via an helper class). I created a new page in the Identity pages that manage the user account to link its YouTube account:
I created a helper class to do the actual upload:
I also had to implement a custom token store to save the tokens for YouTube:
The setup above allows users to link their YouTube account to the website, even if they have not logged in using Google as a provider. They can still use Google as a login provider, and it does not affect the YouTube functionality. The setup above should apply to any other Google API. I really hope this helps somebody! 🙂 P.S @LindaLawton I would be curious to know if the work arounds you mentioned look anything like what I have done above. |
Is your feature request related to a problem? Please describe.
There seem to be no built-in way to use the authentication (access_token) you get from an external login (Google) with .NET Identity with Google API.
The best I can find is essentially "don't use Identity, just use OpenIdConnect". Unfortunately, the system I am working on relies on other features that Identity offers, which forces me to having to stick with Identity.
Moreover, I have realised that the GoogleOpenIdConnect authentication returns an authorized user as long as you are logged in to Google on the browser, meaning that I cannot have an "Identity login" at the same time.
I have a set of existing Identity users, all with an external Google login. These users are then assigned roles by the application. Using GoogleOpenIdConnect would prevent me to keep using those roles as far as I understand.
Describe the solution you'd like
Be able to use IGoogleAuthProvider with Microsoft Identity and Google external login (
.AddGoogle()
), like when you use.AddGoogleOpenIdConnect
.Describe alternatives you've considered
Manually intercept the access_token received during the .NET Identity external login and use that to initialize Google API services.
This works, but persisting the token is a problem: implementing a solution that handles security, multi users, caching, refreshing etc would require too many resources
Use
.AddGoogleOpenIdConnect
in conjunction with.AddGoogle
.This doesn't work as the two login seem to conflict with each other - I am logged out of one when I call login with the other.
Additional Context
I am working on a .NET6 Website. This website will have multiple users and will allow them to upload videos to either their Drive account or their Youtube channel.
I can get this to work easily when running locally as I can use the 'Installed Applications' way of authenticating. I cannot get this to work when deployed on a server.
The text was updated successfully, but these errors were encountered: