We Keep Coding

Authorization code flow - how to get Code parameter value

I've implemented an application that redirects to the wso2 identity server login page. If the login is successfull the user is redirected to a page where he can read his profile details.
Based on his role he can perform certain action, like create a new user.
I've implemented an API (http://localhost:8080/add-user) that calls this URL ( https://localhost:9443/t/carbon.super/oauth2/token) to generate the access token with the desired scope (for example internal_user_mgt_create) that I need in order to call
the wso2 SCIM2.0 API (https://is.docs.wso2.com/en/latest/apis/scim2-rest-apis/#/Users%20Endpoint/createUser).
Everything works if I use grant_type=password and I use the user credentials to generate the access token to call the wso2 SCIM2.0 API, but I want to use "authorization_code" as grant_type to avoid sending user credentials in my application.
How can I do that? And I know that one of the parameters that I need to use this flow is "code", where can I get its value?

You can configure authorization code grant in your application by selecting the Code from the Allowed Grant Types list OAuth/OpenID Connect Configuration in your application. [1]
When using the auth code grant your application needs to wso2 authorize endpoint to obtain the authorization code Using this authorization token and client secret you can obtain the access that is capable of calling the scim endpoint.
Refer to following documents for more information
[1]. https://is.docs.wso2.com/en/latest/guides/access-delegation/authorization-code/
[2]. https://medium.com/identity-beyond-borders/generating-access-tokens-using-wso2-identity-server-4d8c084a3bf5

It's harder to provide an exact answer to this question without knowing more details about the app and the flow you'd expect your users to go. However, it'd be much easier if you have a better understanding of the OAuth2 code grant type. The following is the basic flow.
The user accesses your application through a web browser.
Your application redirects the user to the identity server, with the following parameters in the request.
client_id=xxx
response_type=code
redirect_uri=yyy - Location in your application where you want to get the authz code. This needs to be registered with the IS service provider beforehand.
scopes
The IS prompts the user to log in.
The IS then redirects the user to the given redirect URI, with the authorization code.
Once the code is received by the client, it makes a back channel call to the token endpoint of the IS (https://localhost:9443/t/carbon.super/oauth2/token) with the following parameters.
grant_type=authorization_code
client_id=xxx
client_secret=zzz
code=ccc
IS validates the code and issues an access token.
Read more on OAuth2 here.
Now, if you're getting the "Inactive authorization code" error, your application might already be calling the token endpoint with the code received, before you call your add-user API.
Ideally, your add-user API shouldn't call the token endpoint at all. You should call the token endpoint from your application, get an access token and pass that to the add-user API if needed. Or you can directly call the SCIM API from your application itself.
I hope this helps!

Getting user info (Google API libraries for Java)

I have:
// package com.google.auth.oauth2;
UserAuthorizer userAuthorizer =
UserAuthorizer.newBuilder()
.setClientId(of(clientId, clientSecret))
.setCallbackUri(create(callbackUri))
.setScopes(asList(scopes))
.build();
then I am able to do:
userAuthorizer.getCredentialsFromCode(authorizationCode, create(baseUri)).getRefreshToken();
(This is oauth flow initiated from client side through oauth2 dialog and providing accessing access code)
I have difficulty finding how from that standpoint I can get something like UserInfo (profile picture and / or email)?

Short answer: You can't. Because User Information has nothing to do with OAuth2.
Actually it looks like:
User <-> Client <-> Remote OAuth2 Server <-> Remote App
You might confuse Client with User here. The Client might e.g. be a Third Party Provider which acts as a broker between a User and the App. From an OAuth2-POV the ClientId and ClientSecret thus have nothing to do with any actual User. The Tokens (Refresh or Access) are just so that the Client can tell the remote server, that it (the Client) really is who it says it is and the server can verify this claim.
The Access token received from the Remote OAuth2 Server will then allow your User to access certain EndPoints at the Remote App, by including the Access token in the Request (usually body or header, depending on API implementation). This is, because your Client has identified itself to the Remote OAuth2 Server.

How to access Graph API from a Web API with ADAL JS issued implicit grant token

I have a Web API built in Java that returns database information to an SPA. I need to check the user's group information using AAD Graph API before delivering the response. Right now the Web API accepts the request and reads the user's token (eyJ...).
What are the next steps for the application to be ready to send a request to Graph API on behalf of the user?
I have tried sending the request with the Authorization: Bearer ey... header using the user's token but receive a Authentication_MissingOrMalformed error. I have also tried various edits to the app manifest and delegated permissions with no luck.

The access token that your API received is intended only for your API. What you need is to obtain a new access token, on behalf of the current user, for the Azure AD Graph API.
Fortunately, this is exactly what the on-behalf-of flow is for. From Authentication Scenarios for Azure AD:
Delegated User Identity with OAuth 2.0 On-Behalf-Of Draft Specification
The flow discussed below assumes that a user has been authenticated on another application (such as a native application), and their user identity has been used to acquire an access token to the first-tier web API.
The native application sends the access token to the first-tier web API.
The first-tier web API sends a request to Azure AD’s token endpoint, providing its client ID and credentials, as well as the user’s access token. In addition, the request is sent with an on_behalf_of parameter that indicates the web API is requesting new tokens to call a downstream web API on behalf of the original user.
Azure AD verifies that the first-tier web API has permissions to access the second-tier web API and validates the request, returning a JWT access token and a JWT refresh token to the first-tier web API.
Over HTTPS, the first-tier web API then calls the second-tier web API by appending the token string in the Authorization header in the request. The first-tier web API can continue to call the second-tier web API as long as the access token and refresh tokens are valid.
Be sure to configure your API to request the right set of permissions for the Azure AD Graph API.
Edit: If you are constructing the token request yourself, the request that your API would make to Azure AD to get a new token to the Graph API on behalf of the current user would be a POST against:
https://login.microsoftonline.com/{tenant-id}/oauth2/token
With the following parameters in the body (un-encoded, for readability, in reality these would be application/x-www-form-urlencoded, of course):
grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer&
requested_token_use=on_behalf_of&
assertion={access-token}&
client_id={api-client-id}&
client_secret={api-client-secret}&
resource=https://graph.windows.net&
scope=openid
Where {tenant-id} is the directory identifier (domain name or Guid value), {access-token} is the access token that your SPA provided to your API (the one you're exchanging for an access token to the Graph API), {api-client-id} is the client ID for your API, and {api-client-secret} is the API's secret password credential.
(Note, for simplicity, this example uses password credentials (client_secret) to authenticate the API, though it could very well be using instead an assertion signed by a client certificate.)

Authenticating a user using Google

I'm having a hard time wrapping my head around how to authenticate a user in my REST service. I plan to use Google Sign-in (on Android, namely). I can't quite figure out how to authenticate users on my server. I do not want to have any authorizations (other than validating the identity of the user), all I want to do is when I receive a request, validate that the user is who he (or she) says he is.
My understanding is that the user will login, get some sort of token from Google, then send that token along his request to my server which I will use to validate his identity. However, from what I read, the user will encode their requests in a JWT (json web token), which I will then use to validate their identity without ever talking to the Google server directly. Did I understand properly?
On Google's documentation, it says
If you do not require offline access, you can retrieve the access token and send it to your server over a secure connection. You can obtain the access token directly using GoogleAuthUtil.getToken() by specifying the scopes without your server's OAuth 2.0 client ID.
But it does not say what the server should do with the token.

You have an android app which enables user to log in via Google+ Sign-In, and then this Android app will call your REST API. What you want is how your service authenticates this request. This Android client will send request to your service with token, and you need to validate this token for authentication. Is my understanding right?
If so, you need to validate the token sent to your service. The reference you mentioned is for Google API calls, in your case; it's your own service API call. For the Android side, just follow the reference, in your service side you can use TokenInfo validation to authenticate users.

Java: Access an API that uses SAML authentication

I have a web project that needs to pull some data from a hosted versionone instance. The versionone instance uses SAML authentication for single sign-on.
The single sign-on itself uses a username and pin+one-time password for authentication so it is nearly impossible to hard-code those values into the application.
Is there a way to handle this situation? Can I set something in the header of the request to bypass the single-signon process?

As of release 13.1, VersionOne supports OAuth2 for authentication against the API endpoints. Both the Webserver flow (where the hosted instance POSTs auth tokens to your waiting HTTP server) and the Out-of-band flow (where the hosted instance gives the user a code to copy/paste to the client) are supported.
That may be a better match for your requirements, as the SAML process is difficult to complete without a web browser and user present.
Once the OAuth2 credentials are obtained by the app, it can operate without user intervention. At any time, the user may revoke the app's permissions inside of VersionOne.
With OAuth2, the process is:
Register your app with VersionOne, thus creating a client secret
Configure the app with the client secret data from the registration
Have the app request a permission grant, which sends you to the VersionOne server.
Login to the server as the user you wish the app to act as, and accept the grant.
Copy the grant code back to the app if using the out-of-band flow.
The app contacts the VersionOne instance and exchanges the code for a persistent token.
The app can apply the token as an "Authorization: Bearer " HTTP header to achieve access to the VersionOne endpoint
If the token has expired and the request returns Unauthorized, the client may attempt to refresh the token and try again, without user intervention.
There is some documentation available on the VersionOne community site.
And a few (in-progress) examples in the VersionOne OAuth2 Examples repository
We also have a (beta) HTTP proxy that can run on your app's server, forwarding requests to the VersionOne instance after wrapping them with OAuth2 and SSL.