I know that it is possible to manage IdentityServerv4 clients registration using AdminUI. However, I'd like to manage these registrations using APIs, is it possible?
Related
I am creating a connection between a clients Shopify store and an order management system called Extenda NYCE. For this I have created a custom app and given it all necessary accesses via the Admin API congifurator.
When I've configured the app and installed it in Shopify backend I use the API keys to get access to it via the order management system, but I get an error. Due to poor UX I can't see the whole error message but basically what I am doing is I try to make an article import by using the API keys.
Now I've tried to find a solution to this by reading about using API keys and I seem always to end up in information regarding access tokens and the need of implementing access to these so that the third-party system can get access to the API.
I'm totally lost so I figured why not look it up with StackOverflow. Have you had similar experiences? To me it just seems way too advanced if I need to write scripts to generate access tokens so that the API can have access to the shop data. Isn't the API interface developed NOT to have the need of writing code in Shopify?
I am working on a project that allows a user to create a user to create app keys or secrets so that specific services can be used by external clients. A user can create multiple secrets that they can choose to use across multiple clients.
For this I am planning to create a decoupled auth server that will use identityserver4.
What really holding me back is that I am not sure whether or not I should create an API layer at the auth server. The reason I am considering API at auth server is so that I can create sort of an admin portal client that will give the users a front-end for creating, renewing, and accessing their app keys/secrets. Even the admin portal is going to be a de-coupled angular application.
There are two things that are holding me back at the moment:
I am not sure if it's a good or safe idea to serve this data via
an api layer. From what I understand, identityserver will not be able to provide functionality that allows me to access a list of a user's clients through an endpoint but please correct me if I'm wrong and there's a better way to approach this.
I know we can easily create new clients and persist it into the database with identityserver4 and I am planning to use ClientCredentials grant types for user clients, but is there a link at the database and identity level between a user and a client? Or will I need to create that functionality by myself?
So far I've looked but I have not bee able to find examples that are similar to my situation with identityserver4
Sorry for the noob question, I am just getting into identityserver and web security in general so many of these concepts are still very new to me.
For number 1, I would say yes you can create an API layer to server data. If you check the IdenttiyServer4 AdminUI, Rock Solid has also use the admin API behind the UI. But you must consider encryption, TLS and other security mechanism to keep this safe.
AFIK for number 2, there are no links at identity level between a user and a client. You have to create that by yourselves.
Basically, you need a system that supports Multitenancy. I have achieved that by adding a TenantId field in the AspNetIdentity user table. And also added the tenant Id to claim list.
Please do not hesitate to correct me if i am wrong.
I want to create a custom API that behind the scenes, call number of other APIs which use OAuth 2.0 for authentication. I want to manage this internally so that my custom endpoint somewhat abstract this.
Or to begin with I want to do what app like buffer (https://buffer.com) do - where you connect to different social services and than post your status.
How can I achieve this in .NetCore ?? I don't want to login with these (a lot of samples are catering this scenario), user login is different than this. I just want to establish these connections (like API Connections if you look at Azure API Management) and then perform some operations against those endpoints.
I hope i convey my point. please let me know if this isn't clear.
Thanks
Sanjay
OAuth2 systems are all based on the same workflow.
here's an authorization url, you pass some ids in an authorization header, if everything is correct you get a token, you then use the token to do whatever you are allowed to do. What changes are the credentials you use for authentication and the urls you hit for the various parts of this workflow.
You could write your own OAuth2 library which deals with all this, that's pretty much what I did and simply changed the details for every specific system I had to interact with.
This being said you can always use one of the existing implementations to connect to the various systems you care about, they all have an API you could use, all you have to do is make sure you follow the OAuth2 flow correctly.
I'm attempting to build an ASP.NET Core API with authentication/authorization handled by IdentityServer4. IdentityServer4 is being backed by both Identity and Entity Framework Core. My goal is a fairly standard and familiar set up, where users can login into a API developer portal where they can add "applications" (clients) and have a client id and client secret generated that they can then use to access the API, similar to how Facebook, Google, etc. handle API access.
My mental block is coming with the way IdentityServer handles Entity Framework integration. Their entities are attached to two different contexts, ConfigurationDbContext and PersistedGrantDbContext. I'm at a loss for a good way to associate one or more Client entities from IdentityServer4.EntityFramework with one or more ApplicationUser entities from my Identity context.
This seems like it would be a fairly common usage scenario, but the documentation is strangely silent on it. I've also been unable to find anything online after various and sundry searches. I'm hoping someone else has needed this same setup and can give me some advice on how to proceed.
There is no association between users and clients. IdentityServer authenticates users regardless of which client they are trying to access.
If you want to implement something like "which user is allowed to use which client" semantics, that is beyond authentication. This is typically implemented in the application itself since this is application specific logic.
https://leastprivilege.com/2017/07/10/authorization-is-hard-slides-and-video-from-ndc-oslo-2017/
I have an API which I'd like to secure using OAuth. My API is accessed with a web frontend used by real human users all with their own account (a couple of thousand), and it is also used by the API of some partner companies (less than a hundred), which should also have separate accounts.
I would like to secure the API using OAuth, and I have to decide how to represent the different users. In OAuth, there are two different concepts, clients and users, where client is the higher level concept, and every user is under one of the clients.
I can think of two different ways to represent these API accounts:
Have a single client, and have a separate user for every human user, and for every partner API.
Have one client for the human users, and a separate user for every human user. And have a separate client for every partner API.
Which of the two approaches would be the more idiomatic approach in OAuth? From a technical standpoint I don't see too much advantage or disadvantage of either solution.
(I'm partly confused because the client credential flow is described to be used for API-to-API authentication, which seems to make sense for authenticating the partner APIs. However, most of the OAuth guides also say that it should only be used for trustful APIs (whatever that means), or even internal APIs, but these partner APIs are definitely not internal.)
Implementation will be unified if there is separate client behind every app (including JS one, for users accessing your API via web frontend).
Also it will be possible to manage ACL per app in this case, which will define maximum privileges for the users (users may choose to give less privileges to the app).
On the other hand, simpler approach is to use Cookies for web frontend users and OAuth for partner applications. But in this case you need to support both authentication options.