My current auth server doesn't support OAuth 2.0 and I'm trying to set up a new auth server. But I don't need a replacement, I just want to pass the token to my new auth server so it can give access token to a third-party application.
I've been reading many documents about OAuth2 but none of them mentioned how is the access token generated. All of them only said once the user submitted their credential to the authorizaURL, it will verify and send back a code(auth code grant) or an access token(implicit grant).
The problem is, how does the auth server generate that token and how does the resource server verify this token? And how do these two servers bounded together?
Thank you in advance : )
Related
I'm developing a set of microservices exposed as REST through WSO2 API manager.
Now, I'd like to call these services in Angular front end. What is the best way to handle user authentication and authorization?
I found it can be done through OAuth2 Password Grant as described here?
When user logs in, user credentials will be sent to specific WSO2 APIM endpoint (/token), it validates, generates the token and this token will be sent in header for subsequent calls.
Is this the best approach to this case?
Thanks in advance,
As mentioned in your question, https://apim.docs.wso2.com/en/next/learn/api-security/oauth2/grant-types/password-grant/
This method will only work when you have the resource owner's username and password.
Take an example, suppose you have published the APIs and created a user (resource owner) in the WSO2 store. this user is subscribed to the API using the application. the application will have a client id and secret, which will be used to generate the OAuth2.0 token. this token will be used to invoke the APIs.
Now in your angular project, one way is to hardcode the base64(clientid:clientsecret) and call the token API to generate the OAuth2.0 bearer token. use the generated token to call the APIs onboarded on WSO2. To protect your APIs from the attack, use rate limiting based on IP
Now take another situation, if you want the user to authenticate first, then generate the JWT token for that user using the password grant type (using actual user's username and password), and using that JWT generate the OAuth2.0 Bearer token which will be used to call the APIs.
Steps to be performed for the second situation:
during registration (from Angular), internally onboard the user in the WSO2 Identity Server. (There is a WSO2 API for the same)
After registration, generate the JWT token from the identity server by authenticating username and password. (Again for this, WSO2 API is there)
now using this JWT token, Generate the OAuth2.0 token from WSO2 APIM
use this token to call the APIs
The second approach is the ideal approach for user to service authentication and authorization using WSO2 as the gateway while the first approach mainly focuses on service to service authentication and authorization
Hope this answers your question
Reference Link: https://medium.com/wso2-learning/how-to-protect-your-apis-with-self-contained-access-token-jwt-using-wso2-api-manager-and-wso2-75673d8a4686
I'm successfully getting an access token to resource https://manage.office.com from https ://login.microsoftonline.com/MYTENANTID/oauth2/token using grant_type client_credentials with my client ID and client secret.
But I always get "Authorization has been denied for this request" back when I try to use that token with to start a subscription using https ://manage.office.com/api/v1.0/MYTENANTID/activity/feed/subscriptions/start?contentType=Audit.SharePoint
There is only one Tenant. My app is in the same tenant I'm trying to access.
Do I have to do the client certificate thing with the manifest or can I use the secret key? This is service to service. Or is it that I'm not getting an authorization code first? I didn't think I needed to do that since this scenario doesn't require content
Any help greatly appreciated.
Based on the test, I am also not able to call this rest via the token request with the client id and secret.
To use this API, you can generate a self-signed certificate. Detail step about use certificate to request the app-only token please refer here.
Generally OAuth definition says that it is way where user gives an application access to his resources stored in other application (without exposing the actual username and password). But inside Owin, it is a way to implement token based authentication within an application. Although we can deploy the Authorisation application at different server. But crux remains the same. Could anybody shed some light. I am very confused.
Thanks in advance
If you take a look at the OAuth 2.0 spec you will find this:
The authorization process utilizes two authorization server
endpoints (HTTP resources):
o Authorization endpoint - used by the client to obtain
authorization from the resource owner via user-agent redirection.
o Token endpoint - used by the client to exchange an authorization
grant for an access token, typically with client authentication.
As well as one client endpoint:
o Redirection endpoint - used by the authorization server to
return
responses containing authorization credentials to the client via
the resource owner user-agent.
Not every authorization grant type utilizes both endpoints.
Extension grant types MAY define additional endpoints as needed.
So basically, you have 2 options:
1) Use the authorization endpoint where your end-user is redirected to a form that is handled by the authorization server
OR
2) Create your own form inside your app, get the end-user credentials and send that data to the authorization server, where it will be validated and return a token for you to use.
When requesting access to an application via OAuth 2.0 you need certain credentials. In the case of google the request URL which sends the user to a page to allow access contains the client ID and Secret. Does this not leave the data open for anyone to grab request access to apps on my applications behalf?
Also, is OAuth only possible through a browser or can it be achieved completely server side?
I'm pretty new to this so apologies if I'm missing something obvious.
Your calls to the OAuth 2.0 authorization server which contain your client ID and client secret MUST be made over an encrypted channel (= using SSL/TLS). The standard says (chapter 2.3.1):
The authorization server MUST require the use of TLS as described in Section 1.6 when sending requests using password authentication.
I am following this tutorial about OAuth2.0 https://developers.google.com/youtube/v3/guides/authentication
It looks quite clear how OAuth2.0 works. But I have a bit confusion at the access token part.
After obtaining an access token for a user, your application can use
that token to submit authorized API requests on that user's behalf.
The API supports two ways to specify an access token: Specify the
access token as the value of the access_token query parameter:
www.googleapis.com/youtube/v3/videos?access_token=ACCESS_TOKEN
if someone acquired this access token during the url transferring they can access this protected resource right?
How the server know if the request is coming from the client initially requested the access token?
UPDATE:
after reading this post Are HTTPS headers encrypted? my confusion is cleared. I thought query string is not encrypted during transmission in the network.
Generally I think the consensus is that OAuth 2.0 is a server side technology and all access tokens and communication should be transmitted using SSL as the bearer tokens need to be kept as secure as possible.
Also, you need to know that there are 2 types of flows in OAuth 2.0
i) Implicit grant flow - This is the flow where the user logs in to the service provider and his browser gets the access token. Say you have X.com and Log in via Facebook. Once the user keys in his FB credentials, the access token is sent to his browser.
ii) Authorization Code flow - In this flow (consider the above situation again), facebook will pass an authorization code to the user's browser. If anyone, somehow, intercepts the authorization code there is nothing he can do. An authorization code can be exchanged for an access when passed with valid client credentials. So, when the user logs in, his browser gets an authorization code which is passed to your server at X.com. from there you would hit the code-token exchange endpoint provided by FB and get the access token returned to your server!
Authorization code flow adds another layer of security, where the access token is visible only to the client + server and not to the user agent. And as you figured out yourself, the token is passed via HTTPS.