Temporary authorization management for mobile apps

Last Updated: Jul 03, 2017


Assume an enterprise A has developed a mobile app and has bought OSS for it. The mobile app must upload and download data to and from OSS. However, enterprise A does not want to allow all apps to use the AppServer to transmit data. Instead, enterprise A wants the apps to directly upload and download data to and from OSS. Because the mobile app runs on user devices, these devices are out of control of enterprise A. For security reasons, enterprise A cannot save the access key in the app. Enterprise A also wants to minimize its security risks by, for example, giving each app an access token with the minimum permissions that the app needs to connect to OSS and restricting the access duration to a specified period of time (such as 30 minutes).


  • The mobile app needs to directly transmit data to OSS, without using a data proxy.
  • Enterprise A cannot give an access key to the mobile app because the mobile devices are under the control of A’s users.
  • The access permissions of each mobile app must be restricted, with the granularity accurate to OSS objects.

Solution: Use RAM STS-Tokens

1. Authorization process

Step 1. Enterprise A creates a role.

  1. Log on to the RAM console and goes to Roles > New Role.

  2. In the Create Role window, select Current Alibaba Cloud Account as the trusted account to use this role and enter oss-readonly as the role name.

After creating the role, A can view the basic role information on the role details page, for example, the global name ARN of the role is:

  1. acs:ram::11223344:role/oss-readonly

The trust policy of the role is (only Enterprise A can assume this role):

  1. {
  2. "Statement": [
  3. {
  4. "Action": "sts:AssumeRole",
  5. "Effect": "Allow",
  6. "Principal": {
  7. "RAM": [
  8. "acs:ram::11223344:root"
  9. ]
  10. }
  11. }
  12. ],
  13. "Version": "1"
  14. }

Step 2: Enterprise A grants permissions to the role by binding a suitable authorization policy to it.

After creating a role as described in the previous step, A can follow the prompts to go to bind authorization policies to the role. Or go to the role details page and then click Edit Authorization Policy to bind authorization policies to the role.

In the authorization window, A can select a system authorization policy, such as AliyunOSSReadOnlyAccess, and then click OK.

Step 3: Enterprise A creates a RAM-User for the AppServer and authorizes this user to assume the role just created.

  1. Log on to the RAM console and goes to Users > New User.
  2. In the Create User window, specify a username such as appserver and select the Automatically generate an Access key for this user check box to create an access key.
  3. Click the created user to open the User Details page and then click User Authentication Policies > Edit Authentication Policy.
  4. In the Edit Individual Authorization Policy window, select a system authorization policy such as AliyunSTSAssumeRoleAccess for this user, and then click OK.

2. AppServer issues STS-Tokens for resource access

RAM-Role Identity Access

Step 1: The AppServer uses the RAM-User appserver’s access key to call the STS AssumeRole API.

For example, it can use the aliyuncli to call AssumeRole (note: an access key must be configured for appserver; the access key of A (that is, the primary account) cannot be used:

  1. $ aliyuncli sts AssumeRole --RoleArn acs:ram::11223344:role/oss-readonly --RoleSessionName client-001
  2. {
  3. "AssumedRoleUser": {
  4. "AssumedRoleId": "391578752573972854:client-001",
  5. "Arn": "acs:ram::11223344:role/oss-readonly/client-001"
  6. },
  7. "Credentials": {
  8. "AccessKeySecret": "93ci2umK1QKNEja6WGqi1Ba7Q2Fv9PwxZqtVF2VynUvz",
  9. "SecurityToken": "CAES6AIIARKAAUiwSHpkD3GXRMQk9stDr3YSVbyGqanqkS+fPlEEkjZ+dlgFnGdCI2PV93jksole8ijH8dHJrHRA5JA1YCGsfX5hrzcNM37Vr4eVdWFVQhoCw0DXBpHv//ZcITp+ELRr4MHsnyGiErnDsXLkI7q/sbuWg6PACZ/jzQfEWQb/f7Y1Gh1TVFMuRjEzR2pza1hUamszOGRCWTZZeEp0WEFaayISMzkxNTc4NzUyNTczOTcyODU0KgpjbGllbnQtMDAxMKT+lIHBKjoGUnNhTUQ1QkoKATEaRQoFQWxsb3cSGwoMQWN0aW9uRXF1YWxzEgZBY3Rpb24aAwoBKhIfCg5SZXNvdXJjZUVxdWFscxIIUmVzb3VyY2UaAwoBKkoFNDMyNzRSBTI2ODQyWg9Bc3N1bWVkUm9sZVVzZXJgAGoSMzkxNTc4NzUyNTczOTcyODU0cgllY3MtYWRtaW544Mbewo/26AE=",
  10. "Expiration": "2016-01-13T15:02:37Z",
  11. "AccessKeyId": "STS.F13GjskXTjk38dBY6YxJtXAZk"
  12. },
  13. "RequestId": "E1779AAB-E7AF-47D6-A9A4-53128708B6CE"
  14. }

Note that if no policy parameters are specified during the calling of the AssumeRole API, this STS-Token has all oss-readonly permissions. If you need to restrict the permissions of the STS-Token, for example, to only allow access to “sample-bucket/2015/01/01/*.jpg”, you can use the policy parameters to further restrict the STS-Token’s permissions. For example,

  1. $ aliyuncli sts AssumeRole --RoleArn acs:ram::11223344:role/oss-readonly --RoleSessionName client-002 --Policy "{\"Version\":\"1\", \"Statement\": [{\"Effect\":\"Allow\", \"Action\":\"oss:GetObject\", \"Resource\":\"acs:oss:*:*:sample-bucket/2015/01/01/*.jpg\"}]}"
  2. {
  3. "AssumedRoleUser": {
  4. "AssumedRoleId": "391578752573972854:client-002",
  5. "Arn": "acs:ram::11223344:role/oss-readonly/client-002"
  6. },
  7. "Credentials": {
  8. "AccessKeySecret": "28Co5Vyx2XhtTqj3RJgdud4ntyzrSNdUvNygAj7xEMow",
  9. "SecurityToken": "CAESnQMIARKAASJgnzMzlXVyJn4KI+FsysaIpTGm8ns8Y74HVEj0pOevO8ZWXrnnkz4a4rBEPBAdFkh3197GUsprujsiU78FkszxhnQPKkQKcyvPihoXqKvuukrQ/Uoudk31KAJEz5o2EjlNUREcxWjRDRSISMzkxNTc4NzUyNTczOTcyODU0KgpjbGllbnQtMDAxMKmZxIHBKjoGUnNhTUQ1Qn8KATEaegoFQWxsb3cSJwoMQWN0aW9uRXF1YWxzEgZBY3Rpb24aDwoNb3NzOkdldE9iamVjdBJICg5SZXNvdXJjZUVxdWFscxIIUmVzb3VyY2UaLAoqYWNzOm9zczoqOio6c2FtcGxlLWJ1Y2tldC8yMDE1LzAxLzAxLyouanBnSgU0MzI3NFIFMjY4NDJaD0Fzc3VtZWRSb2xlVXNlcmAAahIzOTE1Nzg3NTI1NzM5NzI4NTRyCWVjcy1hZG1pbnjgxt7Cj/boAQ==",
  10. "Expiration": "2016-01-13T15:03:39Z",
  11. "AccessKeyId": "STS.FJ6EMcS1JLZgAcBJSTDG1Z4CE"
  12. },
  13. "RequestId": "98835D9B-86E5-4BB5-A6DF-9D3156ABA567"
  14. }

Additionally, the default validity period of the above STS-Token is 3600 seconds. You can use the DurationSeconds parameter to limit the STS-Token expiration time (the expiration time cannot exceed 3600 seconds).

Step 2: The AppServer retrieves and parses the credentials.

The AppServer retrieves the AccessKeyId, AccessKeySecret and SecurityToken from the credentials returned by the AssumeRole API. Because the STS-Token validity period is relatively short, if the application requires a longer validity period, AppServer must re-issue a new STS-Token (for example, issue one STS-Token every other 1800 seconds).

Step 3: The AppServer securely transmits an STS-Token to the AppClient.

Step 4: The AppClient uses the STS-Token to directly access a cloud service API (such as OSS).

The operation commands for aliyuncli to use an STS-Token to access an OSS object are as follows (a STS-Token is issued to client-002):

  1. Configure STS-Token syntax: aliyuncli oss Config --host <OssEndPoint> --accessid <AccessKeyId> --accesskey <AccessKeySecret> --sts_token <SecurityToken>
  2. $ aliyuncli oss Config --host oss.aliyuncs.com --accessid STS.FJ6EMcS1JLZgAcBJSTDG1Z4CE --accesskey 28Co5Vyx2XhtTqj3RJgdud4ntyzrSNdUvNygAj7xEMow --sts_token CAESnQMIARKAASJgnzMzlXVyJn4KI+FsysaIpTGm8ns8Y74HVEj0pOevO8ZWXrnnkz4a4rBEPBAdFkh3197GUsprujsiU78FkszxhnQPKkQKcyvPihoXqKvuukrQ/Uoudk31KAJEz5o2EjlNUREcxWjRDRSISMzkxNTc4NzUyNTczOTcyODU0KgpjbGllbnQtMDAxMKmZxIHBKjoGUnNhTUQ1Qn8KATEaegoFQWxsb3cSJwoMQWN0aW9uRXF1YWxzEgZBY3Rpb24aDwoNb3NzOkdldE9iamVjdBJICg5SZXNvdXJjZUVxdWFscxIIUmVzb3VyY2UaLAoqYWNzOm9zczoqOio6c2FtcGxlLWJ1Y2tldC8yMDE1LzAxLzAxLyouanBnSgU0MzI3NFIFMjY4NDJaD0Fzc3VtZWRSb2xlVXNlcmAAahIzOTE1Nzg3NTI1NzM5NzI4NTRyCWVjcy1hZG1pbnjgxt7Cj/boAQ==
  3. Access OSS object
  4. $ aliyuncli oss Get oss://sample-bucket/2015/01/01/grass.jpg grass.jpg

More References

More references for mobile app direct access scenarios:

Thank you! We've received your feedback.