We are developing application for e-signature on PDF for different users of oru system, which call many docusign APIs and we try use JWT to authenticate the APIs. I able to get token. But I have doubt on one parameter of JWT request body. I refer link https://developers.docusign.com/esign-rest-api/guides/authentication/oauth2-jsonwebtoken.
What do you mean by "The user ID of the user to be impersonated.", I used API account user id.
Please refer my previous query Signer URL for an envelope - calling docusign API and getting 400 bad request error. I think, this is not correct what I use to pass here. However I am getting token.
Please let me know if you want to know more details.
"The user ID of the user to be impersonated." means exactly this, you can impersonate a user or "act on behalf of the user" by providing his userId in the JWT call.
So the impersonated user will be the sender of the envelope.
If you use your account userId you will be acting as the sender
I'm building an API to support user provisioning for other application teams around my company. I have a decent understanding of custom policies and have reviewed the invitation flow in WingTipGames, however the sample app is at times hard to follow given the sheer amount of functionality it offers. I would appreciate some clarification around what features I can ignore, vs what is required to support my use case.
Use Case:
My API's CreateUser method creates the user in B2C with ADGraph, then should generate an invitation link that includes a signed JWT with the user's email address, and finally email the link to the recipient. The new user will click the link, which should redirect them directly to the Invitation policy to reset their password.
Clarification Needed:
I'm struggling with simple generation of the Invitation link. What's shown in the sample seems overly complex for my API. In general I'm confused about the OIDC setup given that my API itself (while separately requiring callers to authenticate) will not be involved at all when the recipient clicks the invite link. And as this is an API not an MVC app, I wonder if the process can be stripped down vs the invitation flow in WingTipGames.
Why is ChallengeAsync called in the Invitation\Create method? Presumably this is why we then land in the OnRedirectToIdentityProvider event. Is the challenge what is somehow intercepted and translated into the invitation link?
Are the classes in WingTipCommon relevant here? Namely the AspnetCore.Authentication.OpenIdConnect extensions, handler, and middleware. Asking because users should never arrive at the API in response to clicking the invite link so perhaps the extra plumbing is unnecessary.
Users will always be in a new browser and session when the click the redeem the invitation link, and will redirect directly to the policy (if I understand correctly). Do I still need to worry about the skipCorrelation and XSRF handling?
Any other general suggestions around what to pull out of the sample and what to ignore to support my use case are appreciated.
Thanks
Mark
The Wingtip Games application implements the following flows for invitations:
An invitation link to an application endpoint. This invitation link contains the e-mail address of the invited user, an invitation expiration, and a HMAC-based signature. When the invitation link is opened, the application endpoint validates the HMAC-based signature and the invitation expiration and, if they are valid, then it redirects the invited user to the policy endpoint. This policy redirection contains a signed JWT with the email address of the invited user.
An invitation link to the policy endpoint. This invitation links contains a signed JWT with the email address of the invited user.
I prefer and recommend the first flow for invitations because the application endpoint can implement the invitation logic before the invitation policy is run (e.g. the application endpoint can validate the invitation expiration and, if it isn't valid, then it can display an error message) as well as after the invitation policy has run (e.g. the application endpoint can display a success message).
To answer your specific questions:
Why is ChallengeAsync called in the Invitation\Create method?
This is called for the second flow for invitations. It is called so that the authentication middleware can generate the invitation link and send the invitation message. It is implemented like this so that the application logic doesn't have to be aware of the application identifier, the policy identifier, or the redirection URIs that are required for the invitation link.
Are the classes in WingTipCommon relevant here?
They are used to support the second flow for invitations. See the next answer.
Do I still need to worry about the skipCorrelation and XSRF handling?
This is implemented for the second flow for invitations. As result of the invitation policy, Azure AD B2C issues an authentication response to the client application, where this authentication response is processed by the authentication middleware. Because the authentication middleware doesn't invoke the invitation policy (i.e. it is invoked by the invitation link), then the authentication middleware must be configured to disable the built-in checks for correlation of an authentication request with an authentication response.
I'm using DotNetOpenAuth for OpenID logins. Google's provider returns a different ClaimedIdentifier depending on the realm of the caller (hostname + port).
Is it safe for me to validate a login based on the email address returned by the OpenID authentication callback vs the claimed identifier itself? i.e. is there a way a user could forge their email address and thus gain access to another user's account if we validate on the email instead of the claimed ID?
I was thinking this would be OK to do as long as the provider is trusted - i.e. we can trust Google not to allow a user to sign in using someone else's email address.
The OpenID 2.0 protocol's security model is built around the Claimed Identifier -- not the email address. So the best approach is to make your Realm consistent. If you can do that, that's the best approach.
It may also be a good idea to store the email address in your user's table so that if your realm ever must change (perhaps your company is purchased by another) you'll be able to migrate your users. But if you plan to do this, you should also store what the OP Endpoint was during authentication when you received the email address so you know whether you can trust it.
Generally, it's unsafe to trust the email address at all. If you trust the Provider (Google in your case) to provide you verified email addresses, then you may trust the email addresses if you verify that it is in fact the Provider that authenticated the user. This can only be done correctly by verifying the IAuthenticationResponse.Provider.Uri value is the one you trust. It cannot be done implicitly just by only offering a "Log in with Google" button because of OpenID's "unsolicited assertions" feature, which allows users to log in with arbitrary Providers regardless of what the RP offers in its UI. And it cannot be done by checking the domain of the Claimed Identifier because of the difference between claimed and local identifiers.
I'd verify that the claimed ID is indeed a google one before using the e-mail in my comparison. That's how StackOverflow does it, too.
I just started integration of OpenID in my website. All the examples I saw store the claimed IDs in cookies. How is it safe?
For example, myopenid.com returns a claimed ID that is {username}.myopenid.com
So if a hacker knows your claimed ID, he can easily hack your account.
Of course you encipher/md5 the ID before putting it into the cookies and using for authentication, but it's like storing a username without password!
Update
Now that I thought more about it, I realized, that you need to be logged in the OpenID provider, so even if the hacker gets the username, he still needs the provider's password to log in. Am I correct?
Update 2
No, update 1 is not correct :) My site cannot check whether the user is successfully logged in or not. All I receive is the claimed ID, and I just have to trust that the user is authenticated. That's really confusing...
Knowing the user's claimed identity isn't enough to authenticate.
Indeed, the user would have to be logged in to his provider, in order to authenticate with your website using that identity.
As for "trusting that the user is authenticated" -- no, you don't trust. As a final part of OpenID authentication you're supposed to verify that the authentication message comes from the provider. There are various security measures in place to ensure that the message is authentic, unaltered, etc.
If you do that, you're sure that your user is properly authenticated by the provider.
Now, since you don't want to do it every time your user makes a request, you store the session information in a cookie. However, you don't store only the claimed identifier (if you decide to store it at all), but a session id -- a pseudorandom number generated at the moment your user logs in. Since it's pseudorandom, no one can guess it, and therefore, knowledge of a claimed identifier itself doesn't mean anything.
If that answers your question, read about session management in your favorite language/framework, as it will tell you how to easily implement such mechanism, and how it works.
In summary: think of OpenID as a replacement for a password verification. You don't need to (and shouldn't) store logins and passwords in cookies, and you don't have to store claimed identifiers. Similarly, you don't verify that the login and password matches every time, but remember that the user is authenticated in a session.
I see these two terms bandied about quite a bit (specifically in web-based scenarios but I suppose it's not limited to that) and I was wondering whether or not there was a difference.
It appears to me that they both mean you're allowed to be doing what you're doing. So is this just a nomenclature thing, or is there a basic difference in meaning?
There is indeed a fundamental difference. Authentication is the mechanism whereby systems may securely identify their users. Authentication systems seek to provide answers to the questions:
Who is the user?
Is the user really who they claim / represent to be?
Authorization, by contrast, is the mechanism by which a system determines what level of access a particular (authenticated) user should have to resources controlled by the system. For an example that may or may not be related to a web-based scenario, a database management system might be designed so as to provide certain specified individuals with the ability to retrieve information from a database but not the ability to change data stored in the database, while giving other individuals the ability to change data. Authorization systems provide answers to the questions:
Is user X authorized to access resource R?
Is user X authorized to perform operation P?
Is user X authorized to perform operation P on resource R?
Steve Riley has written a quite good essay on why they must remain distinct.
Authentication refers to verifying an entity's identity. Authorization deals with what an authenticated entity is allowed to do (e.g. file permissions).
The main point is:
Authentication deals with user account validation. Is this a valid user? Is this user registered in our application?. e.g.: Login
Authorization deals with user access validation to certain feature. Does this user have the authorization/right to access this feature? e.g.: Claims, Roles
In my experience, Authentication usually refers to the more technical process, i.e. Authenticating a user (by checking login/password credentials, certificates etc), whereas Authorization is used more in the Business Logic of an application.
For example, in an application, a user might login and be authenticated, but not authorized to perform certain functions.
Authenticating a user on a website means that you verify that this user is a valid user, that is, verifying who the user is using username/password or certificates, etc. In common terms, is the person allowed to enter the building?
Authorization is the process of verifying if the user has rights/permission to access certain resources or sections of a website, for example, if its a CMS then is the user authorized to change content of the website. In terms of the office building scenario, is the user allowed to enter the networks room of the office.
If I can log-in, my credentials are verified and I am AUTHENTICATED. If I can perform a particular task I am AUTHORIZED to do so.
Authentication verifies who you are and Authorization verifies what you are authorized to do. For example, you are allowed to login into your Unix server via ssh client, but you are not authorized to browser /data2 or any other file system. Authorization occurs after successful authentication........
Compared to the rest of the responses which try to explicitly specify the definition or technology. I'll submit an example can be more valuable.
Here's some an article that makes a great analogy to a passport versus a lock and key
When speaking about authentication (also called AuthN), think about identity. Authentication tries to answer “is this person who they say they are?” It’s a software equivalent of a passport or national ID check. Or to put it in more realistic terms, authentication is a similar process to that moment when you look at another person’s face to recognize that this is your friend from college and not your annoying second floor neighbor.
On the other hand, authorization (also called AuthZ) is all about permissions. Authorization answers a question “what is this person allowed to do in this space?” You can think of it as your house key or office badge. Can you open your front door? Can your annoying neighbor enter your apartment at will? And more, once in your apartment, who can use the toilet? Who can eat from your secret stash of cookies tucked away in your kitchen cupboard?
Authentication verifies who you are and Authorization verifies what you are authorized to do. For example, you are allowed to login into your Unix server via ssh client, but you are not authorized to browser /data2 or any other file system. Authorization occurs after successful authentication.
Authentication: verifying who a user is.
To authenticate, the user provides credential information such as a username and password and if the credentials are valid, the user receives a token that can be sent in with future requests as verification of her authentication.
Authorization: determining what a user is allowed to do.
From the user’s perspective, a successful authorization takes place when she is able to send a request to access a system and do something (such as upload a file in the system) and it works.
Authentication only verifies identity—it confirms that a user is who she claims to be. Authorization determines which resources a verified user can access.
Authentication
Authentication verifies who you are. For example, you can login into your server using the ssh client, or access your email server using the POP3 and SMTP client.
Authorization
Authorization verifies what you are authorized to do. For example, you are allowed to login into your server via ssh client, but you are not authorized to browser /data2 or any other file system. Authorization occurs after successful authentication.
Authorization is a process by which server determines if the client has permission to use a resources or access file.
Authentication is used by a server when the server needs to know exactly who is accessing their information or site.
Simple real time example, If student is coming to school then principal is checking Authentication and Authorization.
Authentication:
Check student ID card it mean He or She belong to our school or not.
Authorization:
Check student have permission to sit in Computer Programming Lab or not.
I have tried to create an image to explain this in the most simple words
1) Authentication means "Are you who you say you are?"
2) Authorization means "Should you be able to do what you are trying to do?".
This is also described in the image below.
Authentication:
It is the process of validating if an identity is true or false. In other words, verifying that a user is indeed the one he or she claims himself/herself to be.
Authentication types:
Username + password type of authentication
Authentication using social accounts
Passwordless authentication
Multifactor authentication
Fingerprint or retina based authentication etc
OpenID is an open standard for authentication.
Authorization
The technique that determines which resources are accessible to a user with a given identity or role.
OAuth is an open standard for authorization.
Authentication:
An application needs to know who is accessing the application. So authentication is related to word who. Application will check it by a login form. User will enter user name and password and these inputs will be validated by the application. Once the validation is successful, user is declared as authenticated.
Authorization is to check whether user can access the application or not or what user can access and what user can not access.
Source: Authentcation Vs Authorization