I'm using dotnetopenauth 3.4.7.11121.
I need to generate an access token for an application(it will supply its id and secret), not for a user, somenthing like what Facebook does.
Is it possible using 3.4.7.11121?
I guess I need somenthing like this scenario
It sounds like you're talking about OAuth 1.0. Based on that assumption...
Just come up with an access token and token secret yourself, store it in your OAuth 1.0 service provider's token database, and give it to your OAuth 1.0 consumer. When the call to service provider comes in, DNOA will validate the token against your access token database and it will show up as valid.
In other words, if you want a non-standard way of issuing OAuth 1.0 access tokens, just do it yourself -- not need to use DotNetOpenAuth for generating the access token as it is just a series of random characters stored in a database table.
Related
I am missing some understanding of OAuth2 access_token hope someone can explain or guide me to what I am missing.
I am using Microsoft Azure AD as an authentication provider for my application, I used the returned id_token after successful authentication to extend it with some additional data custom to my application (to facilitate authorization).
I am doing this throw JWT.sign, I decode the data from id_token and add data then I sign it using a secret key saved at the server.
My question is, can I do the same for access_token? When I tried to do so, I get unauthorized.
Am I doing something wrong? Or this is not possible? And why is this happening, I don't find any request made to MS to validated my new signed access_token.
You should never change tokens issued - this is not a correct thing to do. But your point about using domain specific claims is totally valid - all real world systems need these for their authorization.
OPTION 1
Some specialist providers can reach out at time of token issuance and contact your APIs, to get domain specific data to include in tokens. See this Curity article for how that works. I don't think Azure AD supports this though.
PRIVACY
It is best to avoid revealing sensitive data in readable tokens returned to internet clients. If you include name, email etc in ID tokens or access tokens this may be flagged up in PEN tests, since it is Personally Identifiable Information and revealing it can conflict with regulations such as GDPR.
Curity recommends protecting access tokens by issuing them in an opaque reference token format - via the phantom token pattern.
OPTION 2
An option that would work fir Azure AD is to adopt the following approaches:
Look up extra domain specific claims in your API when an access token is first received, then cache results for further API requests with the same access token. See this Azure AD Code Sample class of mine for some code that builds a custom ClaimsPrincipal. Note that the API continues to validate the JWT on every request.
If the UI needs extra domain specific claims then serve them from your API, which can return both OAuth User Info and domain specific data from its ClaimsPrincipal to the UI. See this API controller class for how that looks. Personally I always do this and never read ID tokens in UIs - which should also never read access tokens.
Applications interacting with Azure AD, receive ID tokens after authenticating the users. The applications use access tokens and refresh tokens while interacting with APIs.
The id_token is a JSON Web Token (JWT) which has user profile
attributes in the form of claims. The ID Token is consumed by the
application and used to get user information like the user's name,
email.
The Access Token on the otherhand is a credential that can be
used by an application to access an API.
So if you need application to access api, there the access token is used and you may follow the suggestion steps provided by Tiny Wang
Similar to id tokens, access tokens are also signed, but they are not
encrypted. As per IETF OAuth (RFC 6749) standard specification ,
access token can have different formats and structures for each
services whereas, id token should be JWT format.
To validate an id_token or an access_token, your app has to validate
both the token's signature and the claims. To validate access tokens,
your app should also validate the issuer, the audience, and the
signing tokens.
So in production application, you should get id token by specifying
“id_token+code” or “id_token+token” as response_type to verify
whether the authentication is correctly succeeded. It means it uses
the id_token for authentication and “code” to exchange access_token
to access the resource for authorization.
In short id_token is used to identify the authenticated user, and the
access token is used to prove access rights to protected resources.
Refer this for the information regarding access token and id token.
Hy, I want to ask if there is any possibility to have 2 types of authotization in the same API, for 2 separate endpoints, one to use client_credentials and the other to use authorization_code? The code is in RAML.
Short answer: Yes, it's possible.
The API should only care about the access token (JWT) & claims (user id, etc.) returned from your auth provider, not the authentication method. (unless it's a business requirement)
User can authenticate himself via a login flow and the receives an authorization code, which is then exchanged for a access token. This is authorization_flow in essence.
Or the request can be authenticated using client id + secret and uses the received access token (client_credentials flow). This access token doesn't contain a user claim (because it's usually done in a machine-to-machine communication).
So unless the API relies on user claims being present in access token, it doesn't matter how you retrieve the it, as long as it's valid.
While starting to integrate auth0, I came across this article
So its clear that to secure apis, all we need is the access_token and that is sent with each http request in the request Authorization header(Bearer scheme).
But then auth0(and possibly other providers) also send an Id_token that contains information about the user. My confusion is that how do I use this id_token to pass user information to my api. ( I have a spa running front end that authenticates to auth0 and gets these 2 tokens).
I can ofc call the userInfo end point in my api to get user info. But then wouldn't this defeat the purpose of the Id tokens?
The ID Token is consumed by the application and the claims included,
are typically used for UI display. It was added to the OIDC
specification as an optimization so the application can know the
identity of the user, without having to make an additional network
requests.
So my question is how do I access user profile in my api using id tokens?
"My confusion is that how do I use this id_token to pass user information to my api"
for that confusion, you just pass your JWT token. while generating JWT token, you need to add user information in payload part in JWT token. When your api get the JWT token, just check your JWT token is correct or not by the use of secret key and if correct, you can get data. How to get is just go from that JWT Authentication for Asp.Net Web Api
ID token is sent from the authorization server as a part of OIDC protocol. The purpose of this is to authenticate the user to your client application (SPA in this case). i.e. to let your API or the application know which particular user authorized the client to access a certain resource on its behalf.
Best way to use the ID token is by decoding and verifying it using a library. This will allow you to verify the signature of the token and any other claim that is included in the token (you can add custom claims to the tokens). Validation of those claims can be used to determine identity of the user and match with the user profile in your API. You will have to check the documentation related to your IdP(auth0) to figure out how to add new claims that are used by the user profile in your API.
I have an Asp.NET Web Api v2 setup where I use OAuth (v2) authentication and JSON Web Tokens (JWT). If a user wants access to an endpoint they need to provide the bearer token in the Authorization header. Users need to submit a username and password and if validated they are given an access token (JWT format) that they can then present in the Authorization header. As long as the JWT contains the role accepted by the endpoint all works well.
Now I would like an automated service (another API from another developer) to access one of my endpoints. How do I go about manually generating an access token that has a long expiration date and they can use to access my endpoint without having to submit a username/password. I would like to make it as simple as possible for the outside API to access my API so I just want to be able to hand them a JWT token that they can place in their code.
I am building an app needs to use the RingCentral API. It is server only (no UI) and it needs to be able to send SMS messages. I have names and numbers stored on the server and do not need access to any other features of RingCentral's API. Is there any way to get a normal API key for RingCentral (like the kind you get when using Google APIs), using OAuth in this situation seems a little cumbersome.
RingCentral supports the following OAuth 2.0 flows with links to the API documentation.
Authorization Code
Implicit Grant
Resource Owner Password Credentials
A static API key is not supported at the moment.
Password grant is only supported for private apps (for use by your organization only), so if you are creating a public app (for use by other organizations), you will need to use the authorization code or implicit grant flows.
All 3 flows are supported in the RingCentral JavaScript SDK. Other SDKs support Authorization Code and Password Grant.
Since you have a private Server-only (No UI) app, you can make the auth process less cumbersome by using password grant without refresh tokens. This way you can pass in the password on each request and not generate too many refresh tokens which can raise production issues with your app. To do this, do the following:
Use the password grant
set refresh_token_ttl to -1 in the OAuth token request so no refresh token is generated
If you are using private Server-only (No UI) platform type, it will use Password flow and Refresh Access Token.
Password flow type app uses Oauth grant_type as password which are less cumbersome and more or less easy way in generating access_token
You just need to pass following headers in your Oauth call https://platform.devtest.ringcentral.com/restapi/oauth/token:
"Accept":"application/json“
"Content-Type":"application/x-www-form-urlencoded“
"Authorization",:"Basic <ClientID:ClientSecret in base 64>
In body, we need to pass the parameters in following way :
username=<account phone number>&password=<account password>&extension=<your extension>&grant_type=password
This is easy and less cumbersome than you think.
If you don't need to generate refresh_token and want to get more simple response with access_token, you can pass refresh_token_ttl=0 parameter in body.
There is nothing called normal API key in RingCentral. You will always have a client id and secret